[security-dev 00649]: Re: code review request: 4773451 Support IP address based virtual hosting in default KeyManager implementation

[Michael Tandy]

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

> 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 at openjdk.java.net?

Done.

Michael


2009/3/3 Xuelei Fan <Xuelei.Fan at 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 at 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.Fan at 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.
>>>
>>>
>>>
>
>