Handling SNI alerts in OpenJDK

[Xuelei Fan]

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
>