Michael Tandy wrote:
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?
Yes.
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?
Yes, a exception should be thrown, the behavior ships HTTPS, LDAPS, or
any other specified spec according to client 's configuration.
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?
Yes, of course.
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.
We can enable it always, I think, just as what the EC extension do now.
But we need to consider a very small part of old servers which are not
ready to read any extension data field, so we might need a approach to
disable all extensions. Maybe adding a new system property to switch
the extension is not so bad . (Personally, I dislike using system
property)
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.
I think it might not a good choice, which abuse the concept of protocol
version, it is easy to confuse the users.
Andrew
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?
|
