It may be that Apache has an issue as well, however, the changed behavior specifically occurred when we upgraded from openssl-0.9.8u to openssl-0.9.8za. There was no change to any other aspect of our apache test installations.
Here's how the scenario unfolded: 1. Our product includes an Apache 2.2.22 server which includes mod_ssl with openssl to provide SSL/TLS support. The server is shipped for both Windows and Linux platforms 2. Prior to June, everything was working fine. We test with a large number of different clients (browsers, .NET, Java, curl, gsoap, custom internal HTTP clients) and all were connecting fine. 3. On June 5th, we saw the announcement of the Man in the middle vulnerability in pre- 0.9.8za openssl libraries, so we downloaded, built 0.9.8za as "shared" and replaced the two relevant libraries (libeay32.dll and ssleay32.dll (the .so libraries on Linux)) 4. Upon making this change, our tests from Java 1.7 and .NET immediately began to fail. Existing .NET clients began to hang during the SSL connection and Java 7 clients began to fail with the error, "handshake alert: unrecognized_name" 5. We used Wireshark with SSL diagnostics enabled to test connecting via .NET to an apache server installed with the 0.9.8u libraries, then after connecting, shut down the apache server and replaced the libraries with the 0.9.8za versions 6. I took a screen capture of the Wireshark results and uploaded the image here: http://imgur.com/md3dEh1 a. I circled the relevant bits of the SSL handshake. b. First is the green circle which shows the connecting to a server with the 0.9.8u libraries c. Second is the red circle showing connection to the same server, but now with the 0.9.8za libraries. d. To summarize the image, following the "Client Hello" TLSv1 packet i. The successful connection displays "TLSv1 1514 Server Hello" ii. The failed connection displays "TLSv1 1514 Alert (Level: Warning, Description: Unrecognized Name), Server Hello" 7. To confirm the results, we replicated the test against a Linux apache server and found the same results. Therefore, my conclusion was that there must be a change in behavior between 0.9.8u and 0.9.8za. Based on the openssl changelog, it seemed likely to me that this was a likely culprit and contacted the list accordingly: "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" It should be noted that we found configuring the "ServerName" directive in the apache configuration to match the hostname used by the SSL client did indeed prevent the alerts. However, because we deploy our servers into a variety of dynamically configured environments where the hostname is many times not known at configuration time, this isn't a viable option for us. Best Regards, Steve Bush On Mon, Jun 16, 2014 at 02:12:07PM -0700, Steve Bush wrote: > We have openssl installed with an apache server and we just > upgraded from 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. Are you sure this is not the result of a change in the Apache version? I see Apache code online that returns SSL_TLSEXT_ERR_ALERT_WARNING when no matching certificate is found. I don't see any recent changes in OpenSSL in the handling of this return value. > 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 This looks to me like an Apache issue. > Here is the relevant entry from the changelog \ > (http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=CHANGES;hb=refs/heads/O > \ > penSSL_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] This commit does not introduce the alert generation. The alert is generated when the server callback returns SSL_TLSEXT_ERR_ALERT_WARNING, as in Apache's ssl_callback_ServerNameIndication() function in some Apache versions. Are you asking that OpenSSL not send a warning despite Apache's request to do so? > 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. Apache should not be requesting the alert, and should return SSL_TLSEXT_ERR_NOACK. -- Viktor. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
