[security-dev 00666]: Re: SNI support in JSSE

[Michael Tandy]

> I have no choice but (c). Personally, I really think SNI is becoming a
> have-to-have feature with the grow of virtualization computing.

Here's a webrev which enables SNI on the client end, whenever not
using SSL 2 Hello, and when system property
"sun.security.ssl.disableHelloExtensions" is unset, or set to "no"

http://michaelt.uwcs.co.uk/openjdk_sni_webrev/


2009/3/2 Xuelei Fan <Xuelei.Fan at sun.com>:
> Michael Tandy wrote:
>>>
>>> Good point. But for FIPS-140 compliant. TLS1.0 should be used, SSL v2
>>> Hello
>>> will not be used in a FIPS validated environment.
>>>
>>
>> On the subject of FIPS, perhaps you can answer a question: I gather we
>> have FIPS support [3], but from the documentation [4] I've got no idea
>> of how to enable it.
>>
>>
>
> FIPS compliant mode is experimental in SunJSSE. I don't think, or I don't
> know there is a public approach to enable it. However, we have test case on
> PKCS11 crypro provider with internal APIs, which looks like:
>    Provider p = a pkcs11 provider;
>    Security.removeProvier("SunJSSE");
>    Provider fipsjsse = new com.sun.net.ssl.internal.ssl Provider(p);
>    Security.addProvider(fipsjsse);   //FIPS enabled here.
>
> Note, this just a show case, please do not use Sun internal APIs directly,
> which may be deleted or changed at any time.
>>>>
>>>> Do you think it's likely a server would require SSL3 or TLS, but
>>>> wouldn't support hello extensions?
>>>>
>>>
>>> Yes, I do remember that some of the current ssl/tls servers may refuse to
>>> accept connections from a client that used TLS extensions. Please refer
>>> to
>>> [1] and [2].
>>>
>>
>> OK, so as I see it our options are:
>> (a) don't include client SNI support in OpenJDK 7
>> (b) include SNI support with no API to turn it off, which will break
>> some servers
>> (c) use a system property to work around the API freeze, add a proper
>> API to the next version, and maintain support for the workaround
>> forever
>> (d) use a system property to work around the API freeze, add a proper
>> API to the next version, and break the workaround in the next version
>>
>> None of those options sound very good to me. What do you think we should
>> do?
>>
>>
>
> I have no choice but (c). Personally, I really think SNI is becoming a
> have-to-have feature with the grow of virtualization computing.
>
> Xuelei
>>
>> Michael
>>
>> [3]
>> http://java.sun.com/javase/6/docs/technotes/guides/security/enhancements.html
>> [4]
>> http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
>>
>
>