On Tue, Jun 17, 2014, Viktor Dukhovni wrote:
> 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?
>
Looking through Apache 2.2 (I'm assuming the OP is using that) we have this:
int ssl_callback_ServerNameIndication(SSL *ssl, int *al, modssl_ctx_t *mctx)
{
... snip ...
else {
ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, c,
"No matching SSL virtual host for servername "
"%s found (using default/first virtual host)",
servername);
return SSL_TLSEXT_ERR_ALERT_WARNING;
}
}
}
return SSLnTLSEXT_ERR_NOACK;
While in the 2.4 sources there is an interesting comment:
else {
ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, c, APLOGNO(02044)
"No matching SSL virtual host for servername "
"%s found (using default/first virtual host)",
servername);
/*
* RFC 6066 section 3 says "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."
*
* To maintain backwards compatibility in mod_ssl, we
* no longer send any alert (neither warning- nor fatal-level),
* i.e. we take the second action suggested in RFC 6066:
* "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."
*/
}
}
}
return SSL_TLSEXT_ERR_NOACK;
So OpenSSL is doing what Apache is telling it to if the OP is using 2.2.x.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
