We have openssl installed with an apache server and we just upgraded to openssl-0.9.8u to openssl-0.9.8za, however we suddenly have large numbers of clients failing to connect. Both .NET and Java 1.7 clients fail with the error "unrecognized_name". When delving into this further using Wireshark, the change in behavior in 0.9.8za to send back the TLSv1 Alert is causing both .NET and Java to reject the handshake.
We've confirmed that setting a servername on the server that matches the client request prevents the crash, however the problem we have is that the servers can be configured and referenced in a huge number of ways: Single-server, clusters, behind proxies (via IP port forwarding), so you might expect to see the following server names in use for a single server: servername; servername.company.net; servername.company.external.net; firewall.company.com; 10.1.1.1; 127.0.0.1; 20.30.40.55; localhost Is there a way to disable this behavior in openssl-0.9.8za or how should we best to deal with this? We have probably two to three thousand servers that are potentially affected Here is the relevant entry from the changelog (http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=CHANGES;hb=refs/heads/OpenSSL_0_9_8-stable) that affected this: Thanks to mancha for backporting the fix to the 0.9.8 branch. *) Fix handling of warning-level alerts in SSL23 client mode so they don't cause client-side termination (eg. on SNI unrecognized_name warnings). Add client and server support for six additional alerts per RFC 6066 and RFC 4279. [mancha] Worse, this does NOT conform to RFC 6066: 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. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. TLS implementations are encouraged to make information available to application callers about warning- level alerts that were received or sent during a TLS handshake. Such information can be useful for diagnostic purposes.
