Michael Tandy wrote:
While in a public DNS server, 172.127.192.1 is assigned to "dummy.sun.com".
It is possible that the getLocalHostname() would return
"the_actual_name_is_dummy_sun_com", which getCanonicalHostName() would
return "dummy.sun.com".
Because the certificate matching the hostname will be used used by remote
peer, instead of the local host. So "the_actual_name_is_dummy_sun_com" means
trouble to the remote side, which has no way to identify it, it is a local
setting of remote side. So we have to use getCanonicalHostName() here.
So the secure server's host name has to be the canonical host name?
e.g. if one IP address hosted both http://www.example.com and
https://secure.example.com the canonical host name for the IP address
would have to be secure.example.com for the right certificate to be
identified, or the SSL server would have to have only one certificate?
Yes. The canonical hostname should be secure.example.com, or the
certificate SubjectAlterName should be of "*.example.com". Otherwise,
which certificate would be selected from key store is unable to
expected. So it is not a solution for virtual hosts on the same IP
address, which would be addressed by SNI.
Thanks,
Xuelei
2. If a client application run on a box with multiple physical network
adapters and share a key store, it is also required to figure out the right
certificate from multiple for a certain connection.
The fix can do that. But SNI cannot. SNI is a ClientHello extension, send
by client side. The server side CertificateRequest message has no such
mechanism.
So I think we need the enhancement, because SNI cannot meet all of the
requirement above.
I see what you mean! I was just thinking of using your fix for this
bug as an example of how we might implement SNI in the future.
BTW, could I cc to security-dev@openjdk.java.net?
Done.
Michael
2009/3/3 Xuelei Fan <xuelei....@sun.com>:
Michael Tandy wrote:
I was wondering - I see you get the host name using:
InetAddress localAddress = socket.getLocalAddress();
hostname = localAddress.getCanonicalHostName();
then you send a certificate matching hostname.
What would be the implications of using getHostName instead of
getCanonicalHostName?
For example, in my working spac box, I would config my /etc/hosts similar
to:
172.127.192.1 the_actual_name_is_dummy_sun_com
While in a public DNS server, 172.127.192.1 is assigned to "dummy.sun.com".
It is possible that the getLocalHostname() would return
"the_actual_name_is_dummy_sun_com", which getCanonicalHostName() would
return "dummy.sun.com".
Because the certificate matching the hostname will be used used by remote
peer, instead of the local host. So "the_actual_name_is_dummy_sun_com" means
trouble to the remote side, which has no way to identify it, it is a local
setting of remote side. So we have to use getCanonicalHostName() here.
I'm thinking we could implement SNI by
overriding the socket's getLocalAddress to send an InetAddress with
the hostname set to the SNI-requested server name, then your code
would select the best key automatically.
Yes, that's the benefits of SNI extension. To make myself understood, let's
look at the requirements of the enhancement , which is different from SNI.
1. the environment of the bug reported against is: several servers run on a
single physical box, which has more than one physical network adapters, and
configured each with different IP address and different certificate. However
the servers want to share a keystore, all certificates are stored into the
same keystore. That means in the keystore, there are multiple key entries
could be used, it is required to select the right one for a certain
connection.
If the client hello message include a SNI extension, it is the primary
function to select one certificate from multiple.for a SNI support server.
You're right here.
However if the client hello message does not include the SNI, we should
also be able find the right certificate out. That's the benefit of the fix.
2. If a client application run on a box with multiple physical network
adapters and share a key store, it is also required to figure out the right
certificate from multiple for a certain connection.
The fix can do that. But SNI cannot. SNI is a ClientHello extension, send
by client side. The server side CertificateRequest message has no such
mechanism.
So I think we need the enhancement, because SNI cannot meet all of the
requirement above.
Thanks very much for looking into this.
BTW, could I cc to security-dev@openjdk.java.net?
Thanks,
Xuelei
Or would we be better waiting until the next JDK version and defining
a clearer way of passing the host name?
Michael
2009/2/27 Xuelei Fan <xuelei....@sun.com>:
I need to get a code review for:
4773451 Support IP address based virtual hosting in default KeyManager
implementation
http://cr.openjdk.java.net/~xuelei/4773451/webrev.00/
<http://cr.openjdk.java.net/%7Exuelei/4773451/webrev.00/>
Thanks,
Xuelei
The bug description:
-------------------------------------------------
When using multiple SSLServerSockets with each listening on
it's own IP address, the JVM is not correctly sending the
correct certificate to the connecting client's web browser.
Regardless of which domain/IP the browser attempts to
connect to, the JVM always maps the domain/IP for the first
listed certificate in the keystore.
Example: domains abc.com, def.com, ghi.com each have their
own self-signed certificate in keystore , each created using
'keytool -genkey' and created in same order. Each also
being domain mapped to their own IP address and served
through their own SSLServerSocket.
When a client attempts to connect to abc.com, all is well.
The correct certificate is presented to the client and
connection succeeds. However, when the client attempt to
connect to either def.com or ghi.com, they are presented
with the certificate for abc.com.
If client connecting to def.com or ghi.com elects to accept
that incorrect certificate, connection succeeds to proper
site, despite use of incorrect certificate. So correct
domain/IP mapping is not the issue.
|
