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