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