Can I get the full exception stacks? Thanks, Xuelei
On 11/17/2015 2:24 AM, Omair Majid wrote: > 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 >
