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
