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/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] 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
