Handling SNI alerts in OpenJDK

Mon Nov 16 20:17:12 UTC 2015

Hello Omair,

I brought this up before, and agree with you that it is a good idea: if the server sends the alert and treats it fatal there is no problem in at least trying to continue. It is also not a security problem because the certificate will be validated (and if it is indeed the wrong server it will be noticed).

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374

I am not sure why it was rejected, most likely because of the unclear warning semantics. However I thi k there is no problem in continuing, either the server cooperates or not, the client will notice. Other implementations handle this less picky and still work.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-----Original Message-----
From: Omair Majid <omajid at redhat.com>
To: security-dev at openjdk.java.net
Sent: Mo., 16 Nov. 2015 20:55
Subject: Handling SNI alerts in OpenJDK

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