Hi, There's an issue with using SNI (Server Name Indication) with OpenJDK. It will abort SSL/TLS connections to a server, when the server gives a "unrecognized name" alert in the ssl handshake. This alert always results in a java exception:
Exception in thread "main" javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name RFC 5246 specifies that there are two alert levels: "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection" "If an alert with a level of warning is sent and received, generally the connection can continue normally" RFC 3546 (TLS Extensions) says: "If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal)." So, with an urecognized_name alert that's not fatal, it is up to the client to continue if it wants to. Most SSL implementations will continue normally after receiving an "unrecognized name" alert with the level "warning". Java, however, does not. Probably because of issues like this, RFC 6066 (TLS Extensions: Extension Definitions) says: "It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable." It would be much better if OpenJDK followed what most other implementations do to remove ambiguity. There are two ways currently available to work around this issue. The first suggested workaround is using "jsse.enableSNIExtension=false". Unfortunately, this is often not a possible solution. This is because TLS needs SNI. RFC 7525 says: "TLS implementations MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066] for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy." And disabling SNI breaks connection to many webservers that rely on TLS. Anything that has to connect to an unknown number of servers needs SNI enabled. The second workaround is to fix the server. Practically speaking, a server administrator will often not define all the virtual hosts if they are supposed to use the default page. And this works with many implementations (including Chrome/Firefox/Internet Explorer) that they test. Unfortunately, this does not work with OpenJDK. So something that "works" for most other clients doesn't work with OpenJDK and it's not obvious that the server needs to be fixed. But perhaps more importantly, if you are just writing a client in Java, you may not have access to fix any misconfigured servers. So, neither of the current suggested workarounds works for all cases. I think we should fix OpenJDK to improve compatibility so that it works - similar to other TLS client implementations - with more servers by treating fatal and warning alerts differently. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
