On 10.07.2013 10:32, William A. Rowe Jr. wrote:
> If you frame this as a fast vote for adoption, and correct the text
> in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
> as well as the .html version, I'll post that in my morning (which is
> still stuck on PDT from my travels).
Ok, so after some further offlist discussion, here's the proposal for
2.2.26, and the patch to be referenced in the 2.2.25 announcement:
- backout r1500108
- apply the attached patch for fixing PR55194
I think we only need one more +1 here on @dev to apply this to 2.2.x.
Kaspar
For the sake of reference, here are some more bits about the gory details:
> Let me explain the purpose of the
> if block with these conditions:
>
> if (hostname_note &&
> sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
> apr_ipsubnet_create(&ip, hostname_note, NULL,
> c->pool) != APR_SUCCESS) {
>
> The second and the third condition are only needed for SSLv3 and TLS
> handshakes, as only in this case, OpenSSL will call
> ssl/t1_lib.c:ssl_add_clienthello_tlsext()... which is the place where a
> potentially improper SNI extension could be added.
>
> In 2.2.x, if sc->proxy->protocol is equal to SSL_PROTOCOL_SSLV2 and
> we're omitting the "sc->proxy->protocol != SSL_PROTOCOL_SSLV2" check,
> then SSL_set_tlsext_host_name() will be called, yes, but the name set in
> OpenSSL's respectve SSL struct is simply ignored later on, as
> ssl/s2_clnt.c - which implements SSLv2_client_method() and ssl2_connect
> - never calls ssl_add_clienthello_tlsext(). Compare this to
> SSLv3_client_method(), TLSv1_client_method() etc., which do call
> ssl_add_clienthello_tlsext().
>
> Or, looking at it from the spec point of view: in a pure SSLv2
> connection (sc->proxy->protocol == SSL_PROTOCOL_SSLV2), there isn't any
> way for OpenSSL to put any extensions into the ClientHello - the
> original SSL 2.0 specification simply doesn't provide any such field in
> its protocol definition.
Index: STATUS
===================================================================
--- STATUS (revision 1500107)
+++ STATUS (revision 1500108)
@@ -93,12 +93,6 @@
RELEASE SHOWSTOPPERS:
- * mod_ssl: Fix "SNI for backend" when compiled against OpenSSL without
- support for SSLv2. Followup to r1497466. PR 55194.
- trunk patch: Does not apply to trunk
- 2.4.x patch: Does not apply to 2.4
- 2.2.x patch:
http://people.apache.org/~rjung/patches/sni-backend-fix-r1497466-2_2.patch
- +1: rjung, covener, trawick
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
Index: CHANGES
===================================================================
--- CHANGES (revision 1500107)
+++ CHANGES (revision 1500108)
@@ -1,8 +1,10 @@
-*- coding: utf-8 -*-
Changes with Apache 2.2.26
+ *) mod_ssl: Fix compilation error when OpenSSL does not contain
+ support for SSLv2. Problem was introduced in 2.2.25. PR 55194.
+ [Rainer Jung]
-
Changes with Apache 2.2.25
*) SECURITY: CVE-2013-1862 (cve.mitre.org)
Index: modules/ssl/ssl_engine_io.c
===================================================================
--- modules/ssl/ssl_engine_io.c (revision 1497466)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1073,13 +1073,16 @@
#ifndef OPENSSL_NO_TLSEXT
/*
* Enable SNI for backend requests. Make sure we don't do it for
- * pure SSLv2 or SSLv3 connections, and also prevent IP addresses
+ * pure SSLv3 connections, and also prevent IP addresses
* from being included in the SNI extension. (OpenSSL would simply
* pass them on, but RFC 6066 is quite clear on this: "Literal
* IPv4 and IPv6 addresses are not permitted".)
+ * We can omit the check for SSL_PROTOCOL_SSLV2 as there is
+ * no way for OpenSSL to screw up things in this case (it's
+ * impossible to include extensions in a pure SSLv2 ClientHello,
+ * protocol-wise).
*/
if (hostname_note &&
- sc->proxy->protocol != SSL_PROTOCOL_SSLV2 &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
apr_ipsubnet_create(&ip, hostname_note, NULL,
c->pool) != APR_SUCCESS) {
