Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.eissing@greenbytes.de
 designates 217.91.35.233 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl:
 mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <20FF6604-7527-41BF-9878-E12EBAA8D2CF@jaguNET.com>
Date: Thu, 2 Apr 2015 09:44:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2542AFC-AB4B-4225-A53A-086F1AD52B9B@greenbytes.de>
References: <20150331171252.78A1AAC013F@hades.apache.org>
 <551AE011.9040000@apache.org>
 <EF9A65AE-FB15-4F40-8D06-9BFC77CB99D3@jaguNET.com>
 <551AE5E2.1050202@apache.org>
 <D34823A3-B8A5-4970-ABBE-72C1C04C5A67@jaguNET.com>
 <50FC4735-37E8-482F-AD78-C099BA4CD8AE@jaguNET.com>
 <989FF0B3-16C4-4648-BBFE-5572F719B05A@greenbytes.de>
 <551C2114.7050303@kippdata.de>
 <3EC909E0-261E-4713-8D69-E641E2EDE1F5@jaguNET.com>
 <69F768A8-9F40-4F5B-AB4D-572FD979A569@greenbytes.de>
 <20FF6604-7527-41BF-9878-E12EBAA8D2CF@jaguNET.com>
To: dev@httpd.apache.org

Any reason to differ from trunk in 2.4?=20

The people using spdy already in a 2.4 will most likely have the NPN =
patch deployed, so they'll have it easy with the trunk changes. The only =
one using the alpn patch, I know of, is myself in mod_h2. And that has =
already been adapted.

So, I myself see no reason to not bring the trunk change into 2.4.

> Am 01.04.2015 um 22:33 schrieb Jim Jagielski <jim@jaguNET.com>:
>=20
> Yeah, I agree. Right now, trunk pretty much uses
>=20
> 	#ifdef HAVE_TLS_ALPN
> 	blah blah
> 	#endif
> 	#ifdef HAVE_TLS_NPN
> 	blah2 blah2
> 	#endif
>=20
> Instead of
>=20
> 	#if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)
>=20
> so that "ripping out" NPN would be easier. The question is
> which to use for 2.4...
>=20
>> On Apr 1, 2015, at 1:59 PM, Stefan Eissing =
<stefan.eissing@greenbytes.de> wrote:
>>=20
>> Well, I took the trunk version, diffed to 2.4.12 and made a patch for =
my sandbox build (removed the non alpn/npn parts). That works for mod_h2 =
after adding callbacks for the npn stuff.=20
>>=20
>> I have no real pref to keep npn and alpn separate or not. my thought =
when merging these was that npn will go away rather soon as alpn is =
supposed to replace it and is afaik the cryptographically more secure =
way (i think npn is prone to mitm downgrade attacks).=20
>>=20
>> cheers,
>> Stefan
>>=20
>>=20
>>=20
>>> Am 01.04.2015 um 19:28 schrieb Jim Jagielski <jim@jaguNET.com>:
>>>=20
>>> Yeah, there is some "overlap" which I'm trying to grok,
>>> since trunk had NPN but not ALPN, so I tried to have the
>>> ALPN stuff self-contained. But not sure if that's the best
>>> way since, for example, alpn_proposefns is adjusted
>>> in ssl_callback_AdvertiseNextProtos(), but that is a
>>> NPN "only" function in trunk, so it uses npn_proposefns.
>>>=20
>>> I'm thinking that in trunk we shouldn't think of
>>> NPN and ALPN as "distinct".
>>>=20
>>>> On Apr 1, 2015, at 12:47 PM, Rainer Jung <rainer.jung@kippdata.de> =
wrote:
>>>>=20
>>>> Hi Stefan,
>>>>=20
>>>>> Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
>>>>> Jim,
>>>>>=20
>>>>> today I converted your commit to a path on 2.4.12 and tested it =
with mod_h2. All fine!
>>>>>=20
>>>>> Then I got a trouble report that alpn negotiation always selected =
"http/1.1" unless SSLAlpnPreference configured something else. This is =
due to the deterministic ordering and "http/1.1." > "h2". So, I made a =
slight modification, attached below.
>>>>=20
>>>> Maybe related but concerning NPN: There was a difference between =
the NPN parts of your original Bugzilla attachment and what was already =
in mod_ssl trunk and therefore was not applied. In your attachment, =
there was some code for sorting in ssl_callback_AdvertiseNextProtos() =
which IMHO does not exist in trunk. Is that part necessary?
>>>>=20
>>>> A second difference: your original addition to ssl_engine_io.c had =
the NPN and the ALPN parts merged in the same code block. In trunk those =
are now two separate pieces coming after each other.
>>>>=20
>>>>> --- modules/ssl/ssl_engine_kernel.c    2015-04-01 =
15:23:48.000000000 +0200
>>>>> +++ =
../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.=
c    2015-04-01 17:53:03.000000000 +0200
>>>>> @@ -2177,7 +2152,7 @@
>>>>> }
>>>>>=20
>>>>> /*
>>>>> - * Compare to ALPN protocol proposal. Result is similar to =
strcmp():
>>>>> + * Compare two ALPN protocol proposal. Result is similar to =
strcmp():
>>>>> * 0 gives same precedence, >0 means proto1 is prefered.
>>>>> */
>>>>> static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
>>>>> @@ -2254,14 +2229,8 @@
>>>>>       i +=3D plen;
>>>>>   }
>>>>>=20
>>>>> -    /* Regardless of installed hooks, the http/1.1 protocol is =
always
>>>>> -     * supported by us. Add it to the proposals if the client =
also
>>>>> -     * offers it. */
>>>>>   proposed_protos =3D apr_array_make(c->pool, =
client_protos->nelts+1,
>>>>>                                    sizeof(char *));
>>>>> -    if (ssl_array_index(client_protos, alpn_http1) >=3D 0) {
>>>>> -        APR_ARRAY_PUSH(proposed_protos, const char*) =3D =
alpn_http1;
>>>>> -    }
>>>>>=20
>>>>>   if (sslconn->alpn_proposefns !=3D NULL) {
>>>>>       /* Invoke our alpn_propos_proto hooks, giving other modules =
a chance to
>>>>> @@ -2280,9 +2249,16 @@
>>>>>   }
>>>>>=20
>>>>>   if (proposed_protos->nelts <=3D 0) {
>>>>> -        ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
>>>>> -                      "none of the client alpn protocols are =
supported");
>>>>> -        return SSL_TLSEXT_ERR_ALERT_FATAL;
>>>>> +        /* Regardless of installed hooks, the http/1.1 protocol =
is always
>>>>> +         * supported by us. Choose it if none other matches. */
>>>>> +        if (ssl_array_index(client_protos, alpn_http1) < 0) {
>>>>> +            ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, =
APLOGNO(02839)
>>>>> +                          "none of the client alpn protocols are =
supported");
>>>>> +            return SSL_TLSEXT_ERR_ALERT_FATAL;
>>>>> +        }
>>>>> +        *out =3D (const unsigned char*)alpn_http1;
>>>>> +        *outlen =3D (unsigned char)strlen(alpn_http1);
>>>>> +        return SSL_TLSEXT_ERR_OK;
>>>>>   }
>>>>>=20
>>>>>   /* Now select the most preferred protocol from the proposals. */
>>>=20
>=20

<green/>bytes GmbH
Hafenweg 16, 48155 M=C3=BCnster, Germany
Phone: +49 251 2807760. Amtsgericht M=C3=BCnster: HRB5782