Improved support for Server Name Indication (SNI) #349

Closed
wants to merge 2 commits into from

3 participants

@ptoomey3

Fixes JRUBY-6891, JRUBY-6944, and should fix JRUBY-6771 (unverified).

Java 7 and greater supports SNI when creating SSL Sockets.
JRuby's origional support performed unnecessary reverse DNS
lookups if the SSL destination was an IP address instead
of a hostname. This patch is more inline with how MRI
works, as it requires the developer to explicitly
set a hostname, thus avoiding any reverse lookups.

ptoomey3 added some commits Oct 17, 2012
@ptoomey3 ptoomey3 Improved support for Server Name Indication (SNI)
Java 7 and greater supports SNI when creating SSL Sockets.
JRuby's origional support performed unnecessary reverse DNS
lookups if the SSL destination was an IP address instead
of a hostname.  This patch is more inline with how MRI
works, as it requires the developer to explicitly
set a hostname, thus avoiding any reverse lookups.
8fbe70c
@ptoomey3 ptoomey3 Merge remote-tracking branch 'upstream/master' 7da35ab
@BanzaiMan
JRuby Team member

Your patch enables a test in the MRI suite that fails. https://github.com/ruby/ruby/blob/v1_9_3_286/test/openssl/test_ssl.rb#L354-370

OpenSSL::SSL::SSContext needs servername_cb attribute: http://www.ruby-doc.org/stdlib-1.9.3/libdoc/openssl/rdoc/OpenSSL/SSL/SSLContext.html

I am not familiar with SSL, so I can't comment much further than this.

@ptoomey3

Hey,
So, I am also not terribly familiar with the openssl codebase. But, I did a bit of digging this morning, and as far as I can tell, the test is not ideal, as it requires that both client SNI and server SNI to be supported for that test to pass. However, the test is run anytime client SNI is detected (i.e. instance_methods.include?(:hostname)). It would probably make sense for that test to really check the following before proceeding:

return unless OpenSSL::SSL::SSLSocket.instance_methods.include?(:hostname) and OpenSSL::SSL::SSLContext.instance_methods.include?(:servername_cb)

I can see why the test was written that way, as it is difficult to validate that client SNI is working without being able to create a server to test against. But, SNI support in Java is new, as of JDK 7, and as far as I understand, it only support client SNI. So, as of now, I don't think it is possible/practical to implement server SNI (i.e. add support for servername_cb) until Java supports it.

In summary, I think it would make sense to augment the test conditions in test_ssl.rb such that one can still move forward with client support for SNI (probably the much more common use case). If that set of unit tests is kepy in sync with MRI, then it might make sense to ask upstream MRI to check for both client and server support for SNI before running that test.

@BanzaiMan
JRuby Team member

@ptoomey3 Thank you for looking into the fitness of the tests. As they come from MRI, do you mind dropping them a note at http://bugs.ruby-lang.org? If you have test cases in mind, that will help tremendously, too.

(cc @nahi)

@headius
JRuby Team member

I incorporated your change and masked out the failing test for now in the following commits. @ptoomey3 Will you follow up with ruby-core about fixing the test? We'd like to unmask it as soon as possible, so we know we're actually doing it right.

commit 1e9086f

Author: Charles Oliver Nutter <headius@headius.com>
Date:   Sat Oct 27 01:17:54 2012 -0500

    Mask newly-failing test enabled by previous commit.

commit 607207f

Author: Patrick Toomey <ptoomey3@biasedcoin.com>
Date:   Wed Oct 17 16:05:13 2012 -0700

    Improved support for Server Name Indication (SNI)

    Java 7 and greater supports SNI when creating SSL Sockets.
    JRuby's origional support performed unnecessary reverse DNS
    lookups if the SSL destination was an IP address instead
    of a hostname.  This patch is more inline with how MRI
    works, as it requires the developer to explicitly
    set a hostname, thus avoiding any reverse lookups.
@headius headius closed this Oct 27, 2012
@ptoomey3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment