Bug 56241

Summary: SNI sends warning upon name not found, RFC 6066 discourages this
Product: Apache httpd-2 Reporter: Jon <nuxi>
Component: mod_sslAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: minor CC: javabrett, mnot, steven.BUSH, ylavic.dev
Priority: P2 Keywords: FixedInTrunk
Version: 2.4.1   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Jon 2014-03-10 14:29:28 UTC
The current TLS SNI spec (RFC 6066) no longer recommends sending back a TLS warning if the name couldn't be found because this is being interpreted as a fatal error by many older SSL libraries with semi-broken SNI support.

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

I assume this is as simple as changing line 1943 of ssl_engine_kernel.c to say NOACK instead of WARNING:

http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?view=markup#l1918


This is particularly noticeable if for some reason someone is using a short DNS name (eg https://issues/ instead of https://issues.apache.org/) with one of the broken SSL libraries that has semi-functional SNI support.
Comment 1 Kaspar Brand 2014-03-30 09:57:40 UTC
(In reply to Jon from comment #0)
> The current TLS SNI spec (RFC 6066) no longer recommends sending back a TLS
> warning if the name couldn't be found because this is being interpreted as a
> fatal error by many older SSL libraries with semi-broken SNI support.

I agree that mod_ssl's current behavior still reflects RFC 4366. Specifically:

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

RFC 6066 has changed this to

               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.

For backward compatibility, I think we should take the second action ("continue the handshake"), i.e. return SSL_TLSEXT_ERR_NOACK as suggested.

> I assume this is as simple as changing line 1943 of ssl_engine_kernel.c to
> say NOACK instead of WARNING:

We can just drop line 1943, essentially, and fall through. Did you already test this with the SSL library which is causing problems for you?
Comment 2 Jon 2014-03-30 20:24:41 UTC
(In reply to Kaspar Brand from comment #1)
> > I assume this is as simple as changing line 1943 of ssl_engine_kernel.c to
> > say NOACK instead of WARNING:
> 
> We can just drop line 1943, essentially, and fall through. Did you already
> test this with the SSL library which is causing problems for you?

I've been running with the patch I described for about 2 weeks. It seems to fix interaction with openssl 0.9.8 (which OSX 10.9 has, wtf apple) and older versions of gnutls
Comment 3 Kaspar Brand 2014-04-05 13:02:12 UTC
Thanks for the feedback. I have just committed this change to trunk, as part of r1585090. Will propose for backport unless there are objections on dev@httpd.apache.org.
Comment 4 Kaspar Brand 2014-04-09 10:04:25 UTC
(In reply to Kaspar Brand from comment #3)
> Will propose for backport

Done with r1585922.
Comment 5 Kaspar Brand 2014-04-18 08:37:48 UTC
Committed to 2.4.x with r1588424. To appear in 2.4.10.
Comment 6 Steven Bush 2014-06-19 17:15:14 UTC
What is the status of the backport to the 2.2 release?  We are using 2.2.27 with openssl 0.9.8za which is affected by this.  In particular, .NET and Java 7 clients fail to connect to recently updated servers.
Comment 7 Yann Ylavic 2015-06-09 09:01:31 UTC
Backport to 2.2.x proposed in r1684336.
Comment 8 Yann Ylavic 2015-06-09 16:15:21 UTC
Backported to upcoming 2.2.30 in r1684462.