> 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....@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 >> > >
