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.
(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?
(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
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.
(In reply to Kaspar Brand from comment #3) > Will propose for backport Done with r1585922.
Committed to 2.4.x with r1588424. To appear in 2.4.10.
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.
Backport to 2.2.x proposed in r1684336.
Backported to upcoming 2.2.30 in r1684462.