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

[Michael Tandy]

>> Would you foresee any problems with ClientHandshaker getting the
>> server's name from Handshaker.getHostSE() ?
[...]
> 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.

Isn't getHostSE() what ClientHandshaker passes to
X509ExtendedTrustManager to verify the certificate matches the
hostname?

So if we connect to a server by IP address, and it returns a
certificate which doesn't match the resolved name, won't that cause a
CertificateException anyway?

In other words, if we request the certificate corresponding to the
resolved name, doesn't that mean we are requesting the only
certificate which doesn't cause a CertificateException?

>> 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?

I was thinking we could enable it all the time - it's standard
behaviour so servers shouldn't have a problem with it. Firefox, for
example, always sends it.

Otherwise, we could add a ProtocolVersion for SNI so users can enable
or disable it with setEnabledProtocols. That way we wouldn't need a
new public API.

What do you think?

Michael



>>
>> 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?
>>>>>
>
>