1296862 - NSS treats `unrecognized_name` as fatal when TLS 1.3 is enabled

Status: RESOLVED DUPLICATE of bug 1304574

(NSS :: Libraries, defect)

Description

[Johannes Pfrang [:johnp]]

Connecting to the URL with security.tls.version.max=4 throws an SSL_ERROR_UNRECOGNIZED_NAME_ALERT.
With security.tls.version.max=3 everything works fine (as do other browsers).

Not sure if it's a Firefox or Server issue, as the alert seems to be ambiguous (Bug 574011).

Comment 1

[Eric Rescorla (:ekr)]

This error code on the client appears to always be the result of the server sending an alert.

http://searchfox.org/nss/search?q=SSL_ERROR_UNREC&case=false&regexp=false&path=

Of course, it could still be a client bug (omitting SNI?) but that doesn't appear to be generally true, so it's probably some sort of compat problem on the server.

Comment 2

[Martin Thomson [:mt:]]

I can't reproduce this one myself.  I run Nightly with 1.3 enabled, but it connects fine with the server choosing 1.2.

Comment 3

[Franziskus Kiefer [:franziskus]]

I can reproduce it with the latest nightly. Looks like we have a wrong TLS version in ss->version [1] and make the SNI warning we get from the server fatal.

[1] http://searchfox.org/nss/rev/9a0e813cfbd1c5637c39eb1d19a34ae13bb4dabc/lib/ssl/ssl3con.c#3864

Comment 4

[Eric Rescorla (:ekr)]

I see. You'll note that this behavior by the server is NOT RECOMMENDED:

   The ServerNameList MUST NOT contain more than one name of the same
   name_type.  If the server understood the ClientHello extension but
   does not recognize the server name, the server SHOULD take one of two
   actions: either abort the handshake by sending a fatal-level
   unrecognized_name(112) alert or continue the handshake.  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. 


We could fix this by checking that ws != wait_server_hello at this point
but I would suggest that we instead leave it as is and tell the server
admin to fix their server.

Comment 5

[Johannes Pfrang [:johnp]]

This is the RFC 6066 text; RFC 4366 previously stated

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

This is the relevant Apache bug:

https://bz.apache.org/bugzilla/show_bug.cgi?id=56241

At least Redhat backported the patch to httpd, but Debian Wheezy (7)'s Apache is based on 2.2.22 and the patch from the Apache team was first released in 2.2.30. I don't know of the Debian team has patched their branch. If not we'd risk breaking connections to all unpatched (and misconfigured) Debian 7 servers if I understand this right.

Comment 6

[Eric Rescorla (:ekr)]

From an ecosystem perspective, it would be better if those servers were fixed, so I think the question is how many there are.

Comment 7

[Johannes Pfrang [:johnp]]

Fwiw, I've asked the Debian and Ubuntu Maintainers to apply the effectively 1-line upstream patch to the affected branches.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835041
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1615410

Comment 8

[Franziskus Kiefer [:franziskus]]

(In reply to Eric Rescorla (:ekr) from comment #4)
> I see. You'll note that this behavior by the server is NOT RECOMMENDED.
> We could fix this by checking that ws != wait_server_hello at this point
> but I would suggest that we instead leave it as is and tell the server
> admin to fix their server.

I think we should fix this nevertheless unless we want to make all pre-server hello alerts fatal in all TLS versions. If that's actually what we want, we should make that clear in the code and 3.27 release notes.

Comment 9

[Martin Thomson [:mt:]]

I have a patch up for this elsewhere.