[security-dev 00621]: Re: SNI support in JSSE

[Xuelei Fan]

Michael Tandy wrote:
> Would you foresee any problems with ClientHandshaker getting the
> server's name from Handshaker.getHostSE() ? I have a working
> implementation doing that at the moment.
>
>   
For a SSLSocket, if it is created with a explicit hostname (such as 
SSLSocketFactory.createSocket("the-target-server.sun.com", 443)), the 
Handshaker.getHostSE() will return the explicit hostname, otherwise 
(such as SSLSocketFactory.createSocket(InetAddress addr, int port)), 
will try to get it from a the local system configured name server 
according to IP address, if cannot get a resolved name, IP address will 
be use.

For SSLEngine, it is set by SSLEngine.setPeerHost().

Because the potential requirement is to connect to a virtual host, which 
likely share the same IP address with many hostnames(such as 
server-1.sun.com, server-1.example.com, etc).. So the client must use a 
hostname instead of IPaddress as the target host. If IP address used, 
the behaviors vary according to the name server.
> ServerHandshaker would be more complicated as you'd have to make sure
> the connection ended up at the right virtual host, to do things
> properly. That would mean modifying interfaces, which we can't do in
> JDK7. What would be your opinion about including client support but
> not server support?
>
>   
It's fine. But I have a question, how could you enable the SNI extension 
for a client? Do you want to enable it all the time?
> There's also the issue that using ProtocolVersion SSL20Hello (which is
> on in the default ProtocolList) breaks SNI support because the 2.0
> hello message doesn't support hello extensions.
Maybe we need to make improvement, when enabled extensions, the 
SSLv2Hello should be disabled.  Will look into this.
>  So if you're using
> (for example) an SSLSocketFactoryImpl, to get SNI support you have to
> wrap it in another SSLSocketFactory to call setEnabledProtocols on
> each SSLSocket and disable SSL20Hello. An example of this situation is
> using an HttpsURLConnection. I guess it would be OK to ask users who
> wanted SNI support to do that, though. What do you think?
>
>   
Yes, need to disable SSLv2Hello. But you can also choose to disable 
SSLv2Hello when enabling SNI extension in the implementation.


Andrew
> Michael Tandy
>
>
> Xuelei Fan wrote:
>   
>> It is appreciate you'd like to investigate it.
>>
>> If you need more information about the current framework of TLS/JSSE,
>> please refer to JSSE reference guide[7]:
>>
>> Currently, there is no way to define a plug-in-able extension(that's my
>> plan in a long run), so if one want to implement a extension, he has to
>> hard-coded the handshaking, on both client side[1] and server side[2].
>>
>> For SNI, there are requirements:
>> 1. For the client side, it meight need a public API in order to set the
>> peer hostname, otherwise get the host name from the request URI.
>> 2. For the server side, the simplest case is to choose a trust
>> certificate for the requested hostname.
>> 3. For virtual host and virtual machine, the server would like forward
>> IP or proxy a connection to the virtual one, so one need to define a
>> callback in order to provide the flexibility that the users could
>> customized their behaviors while getting a SNI extension.
>>
>> In order to meet those requirements on the current framework, one should:
>> 1. modify the clientHello HandshakeMessage [3], support the SNI extensions.
>> 2. modify the trust manager[4] and the key manager[5], get them select
>> the proper certificate according to the SNI.
>> 4. modify the ClientHandshaker[1] and ServerHandshaker[2].
>> 3. add new public API to SSLSocket, or a SSL parameter to SSLSocket[6],
>> indicate what behaviors should be taken when get such a SNI extension.
>>
>> However, because it is not possible to add a new public API at JDK7,
>> maybe you need to hard coded the behaviors while get a SNI at
>> Serverhandshaker.[2].
>>
>> JDK 6 have support ECC extension, I think maybe you could get some hints
>> from there.[8][1][2]
>>
>> Thanks,
>> Xuelei
>>
>> [1]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/ClientHandshaker.java
>> [2]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/ServerHandshaker.java
>> [3]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/HandshakeMessage.java#ClientHello
>> [4]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/X509TrustManagerImpl.java
>> [5]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
>> [6]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/javax/net/ssl/SSLSocket.java
>> [7]:
>> http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
>> [8]:
>> http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/HandshakeMessage.java
>> <http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/HandshakeMessage.java#ClientHello>
>>
>> Xuelei Fan wrote:
>>     
>>> No, and there is no plan to support it at jdk7 at present.
>>>
>>> Xuelei
>>>
>>> Richard Stupek wrote:
>>>       
>>>> Is SNI (Server name indication) slated to be in JDK7?
>>>>