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?
