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

[Michael Tandy]

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.

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?

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

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