You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2015/04/22 10:52:43 UTC
ALPN patch comments
I made two small patches based on the feedback from Kaspar. One for the code and one for the documentation. Since I build against releases, I did not test the doc patch building.
This code patch I tested against my already patched 2.4.12 with openssl 1.0.2 and 1.0.1 in mod_h2 sandbox.
Re NPN support comments: I can sympathize with only bringing „official“ protocols into a release branch (2.4). However there are a lot of openssl 1.0.1 installations out there where httpd 2.4 is deployed which already talk NPN and it might take some time for getting ALPN support from the distros. Which would mean more people building and deploying their own SSL libraries/patching mod_ssl and having no auto update, if they want to use SPDY or HTTP/2. Does not seem like an easy decision.
Cheers,
Stefan
Re: ALPN patch comments
Posted by Rainer Jung <ra...@kippdata.de>.
Am 23.04.2015 um 06:56 schrieb Kaspar Brand:
> On 22.04.2015 21:30, Rainer Jung wrote:
>> Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
>>> Thanks. In the patch for ssl_private.h, the complete NPN block should
>>> actually be dropped - the same block is are already part of
>>> ssl_private.h, just 10 lines above.
>>
>> I've kept the new one and dropped the old one in r1675459.
>
> It's nitpicking, but... the old one was already correct, actually. All
> this stuff is in a larger "#if !defined(OPENSSL_NO_TLSEXT) ..." block,
> so there's no need to repeat NO_TLSEXT.
Oups, fixed in r1675549.
> I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk
> anyway, though, so it's really a very minor point right now ;-)
Agreed.
Rainer
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
I don't know if I have any points to give here, but if NPN does not make it to 2.4, it's fine with me to remove it from trunk also. Only mod_spdy is affected afaik.
//Stefan
> Am 23.04.2015 um 06:56 schrieb Kaspar Brand <ht...@velox.ch>:
>
>> On 22.04.2015 21:30, Rainer Jung wrote:
>>> Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
>>> Thanks. In the patch for ssl_private.h, the complete NPN block should
>>> actually be dropped - the same block is are already part of
>>> ssl_private.h, just 10 lines above.
>>
>> I've kept the new one and dropped the old one in r1675459.
>
> It's nitpicking, but... the old one was already correct, actually. All
> this stuff is in a larger "#if !defined(OPENSSL_NO_TLSEXT) ..." block,
> so there's no need to repeat NO_TLSEXT.
>
> I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk
> anyway, though, so it's really a very minor point right now ;-)
>
> Kaspar
Re: ALPN patch comments
Posted by Kaspar Brand <ht...@velox.ch>.
On 22.04.2015 21:30, Rainer Jung wrote:
> Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
>> Thanks. In the patch for ssl_private.h, the complete NPN block should
>> actually be dropped - the same block is are already part of
>> ssl_private.h, just 10 lines above.
>
> I've kept the new one and dropped the old one in r1675459.
It's nitpicking, but... the old one was already correct, actually. All
this stuff is in a larger "#if !defined(OPENSSL_NO_TLSEXT) ..." block,
so there's no need to repeat NO_TLSEXT.
I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk
anyway, though, so it's really a very minor point right now ;-)
Kaspar
Re: ALPN patch comments
Posted by Rainer Jung <ra...@kippdata.de>.
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
> On 22.04.2015 10:52, Stefan Eissing wrote:
>> I made two small patches based on the feedback from Kaspar. One for
>> the code and one for the documentation.
>
> Thanks. In the patch for ssl_private.h, the complete NPN block should
> actually be dropped - the same block is are already part of
> ssl_private.h, just 10 lines above.
I've kept the new one and dropped the old one in r1675459. The condition
was slightly different. I dropped
#if !defined(OPENSSL_NO_NEXTPROTONEG) && defined(OPENSSL_NPN_NEGOTIATED)
and kept
#if !defined(OPENSSL_NO_NEXTPROTONEG) && !defined(OPENSSL_NO_TLSEXT) &&
defined(OPENSSL_NPN_NEGOTIATED)
Hope that's OK.
Regards,
Rainer
Re: ALPN patch comments
Posted by Jim Jagielski <ji...@jaguNET.com>.
Thank You!!
Will review ASAP.
> On Apr 29, 2015, at 7:05 AM, Kaspar Brand <ht...@velox.ch> wrote:
>
> On 27.04.2015 17:04, Stefan Eissing wrote:
>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>>> certainly needs more eyes before a backport proposal could be made.
>>> There's also a "TODO: we should have a mod_ssl configuration parameter"
>>> in ssl_engine_kernel.c which I'm unsure to what it refers.
>>
>> The „TODO“ is a leftover from before SSLAlpnPreference was introduced.
>> It can be removed.
>
> I did some formatting cleanup in r1676709 and put a patch for 2.4.x
> online under
> https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
> This should hopefully make it easier for people to test and review (it's
> an amalgamation of ten revisions from trunk, see the top of the patch file).
>
> Kaspar
Re: ALPN patch comments
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
The key issue I had with the lack of optional functions on the old NPN
backport is addressed, that's great. Looks promising!
NPN is now irrelevant with ALPN, I presume?
On Wed, Apr 29, 2015 at 6:05 AM, Kaspar Brand <ht...@velox.ch>
wrote:
> On 27.04.2015 17:04, Stefan Eissing wrote:
> >> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
> >> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
> >> certainly needs more eyes before a backport proposal could be made.
> >> There's also a "TODO: we should have a mod_ssl configuration parameter"
> >> in ssl_engine_kernel.c which I'm unsure to what it refers.
> >
> > The „TODO“ is a leftover from before SSLAlpnPreference was introduced.
> > It can be removed.
>
> I did some formatting cleanup in r1676709 and put a patch for 2.4.x
> online under
> https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
> This should hopefully make it easier for people to test and review (it's
> an amalgamation of ten revisions from trunk, see the top of the patch
> file).
>
> Kaspar
>
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
It sounds like it could be a vhost thing. SSL_CTX is most likely not global, but maybe unique for a vhost? I am not certain myself, maybe someone else with more knowledge of mod_ssl could pitch in?
//Stefan
> Am 01.06.2015 um 13:04 schrieb Rainer Jung <ra...@kippdata.de>:
>
> Am 29.04.2015 um 13:05 schrieb Kaspar Brand:
>> I did some formatting cleanup in r1676709 and put a patch for 2.4.x
>> online under
>> https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
>> This should hopefully make it easier for people to test and review (it's
>> an amalgamation of ten revisions from trunk, see the top of the patch file).
>
> Question on that ALPN backport patch and the one in the STATUS file: is it clear that the registration setting up the propose and nego callback function arrays should be per connection? Wouldn't that be more a global or per vhost thing? Just asking because of performance reasons.
>
> Regards,
>
> Rainer
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: ALPN patch comments
Posted by Rainer Jung <ra...@kippdata.de>.
Am 29.04.2015 um 13:05 schrieb Kaspar Brand:
> I did some formatting cleanup in r1676709 and put a patch for 2.4.x
> online under
> https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
> This should hopefully make it easier for people to test and review (it's
> an amalgamation of ten revisions from trunk, see the top of the patch file).
Question on that ALPN backport patch and the one in the STATUS file: is
it clear that the registration setting up the propose and nego callback
function arrays should be per connection? Wouldn't that be more a global
or per vhost thing? Just asking because of performance reasons.
Regards,
Rainer
Re: ALPN patch comments
Posted by Kaspar Brand <ht...@velox.ch>.
On 27.04.2015 17:04, Stefan Eissing wrote:
>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>> certainly needs more eyes before a backport proposal could be made.
>> There's also a "TODO: we should have a mod_ssl configuration parameter"
>> in ssl_engine_kernel.c which I'm unsure to what it refers.
>
> The „TODO“ is a leftover from before SSLAlpnPreference was introduced.
> It can be removed.
I did some formatting cleanup in r1676709 and put a patch for 2.4.x
online under
https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
This should hopefully make it easier for people to test and review (it's
an amalgamation of ten revisions from trunk, see the top of the patch file).
Kaspar
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
I additionally tested today on Ubuntu 14.04 LTS. Works for me.
> Am 03.06.2015 um 12:56 schrieb Stefan Eissing <st...@greenbytes.de>:
>
> I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and openssl 1.0.2. All my tests ran fine.
>
> //Stefan
>
>> Am 02.06.2015 um 16:56 schrieb Eric Covener <co...@gmail.com>:
>>
>> Can you test the latest rev of the backport candidate?
>>
>> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
>>
>>
>>
>> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <st...@greenbytes.de> wrote:
>>
>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>>>
>>> On 22.04.2015 18:54, Jim Jagielski wrote:
>>>>> For me the time seems right to rip NPN out of trunk and only backport
>>>>> the ALPN code to 2.4.
>>>>>
>>>>
>>>> I'd be +1 for that.
>>>
>>> So, to get one step further, and since there were no explicit objections
>>> to removing NPN support so far (or arguments for keeping it, FWIW), I
>>> went ahead and took a stab at this with r1676004.
>>>
>>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>>> certainly needs more eyes before a backport proposal could be made.
>>> There's also a "TODO: we should have a mod_ssl configuration parameter"
>>> in ssl_engine_kernel.c which I'm unsure to what it refers.
>>
>> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed.
>>
>> I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess.
>>
>> Stefan
>>
>>>
>>> Kaspar
>>
>> <green/>bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>
>>
>>
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: ALPN patch comments
Posted by Yann Ylavic <yl...@gmail.com>.
With the current (master) code of mod_h2, you'd probably need
something like the attached patch to handle a possible failure in
modssl_register_alpn(), because SSLALPNPreference was not configured
(as per my proposed mod_ssl patch).
On Wed, Jun 3, 2015 at 5:16 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Hmm, I cannot test this today since I am travelling.
>
> If Jim wants to tag 2.5.13 this week, then either the current v4 patch makes it in, or we need to postpone this. A changed patch on which my module (and possibly others) chokes on, will not serve anyone I assume.
>
> As with the "don't send NPN unnecessary" bug report: ALPN is working slighty different. Not sure if the server cb is triggered at all, if the client sends no ALPN.
>
> //stefan
>
>
>
>> Am 03.06.2015 um 17:04 schrieb Yann Ylavic <yl...@gmail.com>:
>>
>>> On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>>
>>> This means enabling ALPN only if SSLALPNPreference is used.
>>
>> Something like below :
>>
>> Index: modules/ssl/mod_ssl.c
>> ===================================================================
>> --- modules/ssl/mod_ssl.c (revision 1683271)
>> +++ modules/ssl/mod_ssl.c (working copy)
>> @@ -456,6 +456,8 @@ static int modssl_register_alpn(conn_rec *c,
>> ssl_alpn_proto_negotiated negotiatedfn)
>> {
>> #ifdef HAVE_TLS_ALPN
>> + SSLSrvConfigRec *sc;
>> +
>> SSLConnRec *sslconn = myConnConfig(c);
>>
>> if (!sslconn) {
>> @@ -462,6 +464,11 @@ static int modssl_register_alpn(conn_rec *c,
>> return DECLINED;
>> }
>>
>> + sc = mySrvConfig(sslconn->server);
>> + if (sc->server->ssl_alpn_pref->nelts <= 0) {
>> + return DECLINED;
>> + }
>> +
>> if (!sslconn->alpn_proposefns) {
>> sslconn->alpn_proposefns =
>> apr_array_make(c->pool, 5, sizeof(ssl_alpn_propose_protos));
>> Index: modules/ssl/ssl_engine_init.c
>> ===================================================================
>> --- modules/ssl/ssl_engine_init.c (revision 1683271)
>> +++ modules/ssl/ssl_engine_init.c (working copy)
>> @@ -648,7 +648,9 @@ static void ssl_init_ctx_callbacks(server_rec *s,
>> SSL_CTX_set_info_callback(ctx, ssl_callback_Info);
>>
>> #ifdef HAVE_TLS_ALPN
>> - SSL_CTX_set_alpn_select_cb(ctx, ssl_callback_alpn_select, NULL);
>> + if (s->ssl_alpn_pref->nelts > 0) {
>> + SSL_CTX_set_alpn_select_cb(ctx, ssl_callback_alpn_select, NULL);
>> + }
>> #endif
>> }
>>
>> --
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
Hmm, I cannot test this today since I am travelling.
If Jim wants to tag 2.5.13 this week, then either the current v4 patch makes it in, or we need to postpone this. A changed patch on which my module (and possibly others) chokes on, will not serve anyone I assume.
As with the "don't send NPN unnecessary" bug report: ALPN is working slighty different. Not sure if the server cb is triggered at all, if the client sends no ALPN.
//stefan
> Am 03.06.2015 um 17:04 schrieb Yann Ylavic <yl...@gmail.com>:
>
>> On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> This means enabling ALPN only if SSLALPNPreference is used.
>
> Something like below :
>
> Index: modules/ssl/mod_ssl.c
> ===================================================================
> --- modules/ssl/mod_ssl.c (revision 1683271)
> +++ modules/ssl/mod_ssl.c (working copy)
> @@ -456,6 +456,8 @@ static int modssl_register_alpn(conn_rec *c,
> ssl_alpn_proto_negotiated negotiatedfn)
> {
> #ifdef HAVE_TLS_ALPN
> + SSLSrvConfigRec *sc;
> +
> SSLConnRec *sslconn = myConnConfig(c);
>
> if (!sslconn) {
> @@ -462,6 +464,11 @@ static int modssl_register_alpn(conn_rec *c,
> return DECLINED;
> }
>
> + sc = mySrvConfig(sslconn->server);
> + if (sc->server->ssl_alpn_pref->nelts <= 0) {
> + return DECLINED;
> + }
> +
> if (!sslconn->alpn_proposefns) {
> sslconn->alpn_proposefns =
> apr_array_make(c->pool, 5, sizeof(ssl_alpn_propose_protos));
> Index: modules/ssl/ssl_engine_init.c
> ===================================================================
> --- modules/ssl/ssl_engine_init.c (revision 1683271)
> +++ modules/ssl/ssl_engine_init.c (working copy)
> @@ -648,7 +648,9 @@ static void ssl_init_ctx_callbacks(server_rec *s,
> SSL_CTX_set_info_callback(ctx, ssl_callback_Info);
>
> #ifdef HAVE_TLS_ALPN
> - SSL_CTX_set_alpn_select_cb(ctx, ssl_callback_alpn_select, NULL);
> + if (s->ssl_alpn_pref->nelts > 0) {
> + SSL_CTX_set_alpn_select_cb(ctx, ssl_callback_alpn_select, NULL);
> + }
> #endif
> }
>
> --
Re: ALPN patch comments
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> This means enabling ALPN only if SSLALPNPreference is used.
Something like below :
Index: modules/ssl/mod_ssl.c
===================================================================
--- modules/ssl/mod_ssl.c (revision 1683271)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -456,6 +456,8 @@ static int modssl_register_alpn(conn_rec *c,
ssl_alpn_proto_negotiated negotiatedfn)
{
#ifdef HAVE_TLS_ALPN
+ SSLSrvConfigRec *sc;
+
SSLConnRec *sslconn = myConnConfig(c);
if (!sslconn) {
@@ -462,6 +464,11 @@ static int modssl_register_alpn(conn_rec *c,
return DECLINED;
}
+ sc = mySrvConfig(sslconn->server);
+ if (sc->server->ssl_alpn_pref->nelts <= 0) {
+ return DECLINED;
+ }
+
if (!sslconn->alpn_proposefns) {
sslconn->alpn_proposefns =
apr_array_make(c->pool, 5, sizeof(ssl_alpn_propose_protos));
Index: modules/ssl/ssl_engine_init.c
===================================================================
--- modules/ssl/ssl_engine_init.c (revision 1683271)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -648,7 +648,9 @@ static void ssl_init_ctx_callbacks(server_rec *s,
SSL_CTX_set_info_callback(ctx, ssl_callback_Info);
#ifdef HAVE_TLS_ALPN
- SSL_CTX_set_alpn_select_cb(ctx, ssl_callback_alpn_select, NULL);
+ if (s->ssl_alpn_pref->nelts > 0) {
+ SSL_CTX_set_alpn_select_cb(ctx, ssl_callback_alpn_select, NULL);
+ }
#endif
}
--
Re: ALPN patch comments
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
Neither do I, but we can't break non-http/2 configurations with
"modern" browsers.
If "http/1.1" is a MUST in the clients' protocols there is no issue here...
>
> As to the "check for sc->server->ssl_alpn_pref->nelts“ that is very much depending on the order of hooks.
> In the case of mod_h2, registering for alpn happens in pre connection hooks and those run *after* mod_ssl pre_connection hook, I am pretty sure.
Well, ssl_alpn_pref is initialized at config time, so it should always
be filled at connection time (unlike
sslconn->{alpn_proposefns,alpn_negofns}).
This means enabling ALPN only if SSLALPNPreference is used.
RE: ALPN patch comments
Posted by Bert Huijben <be...@qqmail.nl>.
Can we really do ALPN per vhost?
If this is handled before or at the same time as SNI, then SSLAlpnEnable is eventually applied per listening address, while H2Engine would make sense even for multiple hosts at the same ip.
I would say returning some error is a valid response for not enabling H2Engine on a VHost, while still handling ALPN when explicitly disabled is not.
Bert
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: woensdag 3 juni 2015 22:20
To: dev@httpd.apache.org
Subject: Re: ALPN patch comments
That is why mod_h2 allowe "H2Engine on|off" on base server and vhosts. If I understand you correctly, this does what you ask for.
//Stefan
Am 03.06.2015 um 19:45 schrieb William A Rowe Jr <wrowe@rowe-clan.net <ma...@rowe-clan.net> >:
On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing <stefan.eissing@greenbytes.de <ma...@greenbytes.de> > wrote:
Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
The reason boils down to vhosts and interop. If someone does not wish
for a specific vhost (perhaps interacting with bad clients, or created for
backwards compatibility) to respond with a feature, it is useful to have
a fine-grained toggle. The default -could- be 'enabled', although this
probably should not happen on the stable/maintenance branches, but
simply on the future release branch, to avoid surprises.
OpenSSL does the wrong thing in some cases with respect to TLS/SNI
and my current patch development - in some respect - is backing out
that callback change for customers who have been burned by this
specific nonsense. You should reconsider absolutist behaviors,
because they make it much harder for people to inject 'experimental'
behaviors into specific hosts.
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
That is why mod_h2 allowe "H2Engine on|off" on base server and vhosts. If I understand you correctly, this does what you ask for.
//Stefan
> Am 03.06.2015 um 19:45 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
>> On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>> Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
>
> The reason boils down to vhosts and interop. If someone does not wish
> for a specific vhost (perhaps interacting with bad clients, or created for
> backwards compatibility) to respond with a feature, it is useful to have
> a fine-grained toggle. The default -could- be 'enabled', although this
> probably should not happen on the stable/maintenance branches, but
> simply on the future release branch, to avoid surprises.
>
> OpenSSL does the wrong thing in some cases with respect to TLS/SNI
> and my current patch development - in some respect - is backing out
> that callback change for customers who have been burned by this
> specific nonsense. You should reconsider absolutist behaviors,
> because they make it much harder for people to inject 'experimental'
> behaviors into specific hosts.
>
>
Re: ALPN patch comments
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing <stefan.eissing@greenbytes.de
> wrote:
> Hmm, personally, I do not like redundant configurations. If someone
> configures a module, like mod_h2, to be enabled (H2Engine on), she could
> expect the module to take all the necessary steps. So I am no fan of a
> „SSLAlpnEnable“.
>
The reason boils down to vhosts and interop. If someone does not wish
for a specific vhost (perhaps interacting with bad clients, or created for
backwards compatibility) to respond with a feature, it is useful to have
a fine-grained toggle. The default -could- be 'enabled', although this
probably should not happen on the stable/maintenance branches, but
simply on the future release branch, to avoid surprises.
OpenSSL does the wrong thing in some cases with respect to TLS/SNI
and my current patch development - in some respect - is backing out
that callback change for customers who have been burned by this
specific nonsense. You should reconsider absolutist behaviors,
because they make it much harder for people to inject 'experimental'
behaviors into specific hosts.
Re: ALPN patch comments
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
> If a client sends ALPN information in its hello, it certainly can expect an answer from the server.
> Since in absence of any other modules, the httpd will do „http/1.1“, I think that is a reasonable response.
FWICS, httpd will alert if the client did not propose "http/1.1" in
its Hello, and since (I suppose) the latests clients also send ALPN
inconditionaly, they will be refused if they don't propose "http/1.1",
hence my question:
>> Am 03.06.2015 um 14:52 schrieb Yann Ylavic <yl...@gmail.com>:
>>
>> Are those (ALPN ready) always negociate "http/1.1"?
Re: ALPN patch comments
Posted by Jan Kaluža <jk...@redhat.com>.
On 06/03/2015 03:43 PM, Stefan Eissing wrote:
> Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
>
> If a client sends ALPN information in its hello, it certainly can expect an answer from the server. Since in absence of any other modules, the httpd will do „http/1.1“, I think that is a reasonable response.
>
> For clients that do not sent ALPN, any possible answer from the server will not be relevant for them. And I would be surprised if a client gets confused by that. If it uses openssl, it will probably not have registered own callbacks and thus never see the server answer.
I'm not sure if that's the same case, but Red Hat actually has open bug
report for the old 2.4.x NPN code (right now reverted in 2.4.x) about
NPN extensions being sent even they have not been configured.
I think last time I've checked, the httpd trunk ALPN code did something
similar (returned http/1.1 when no other modules have been configured).
The reasoning in that Red Hat bug report is that there should be a way
how to stop this behavior because of compliance with some security
standards.
I just want to point out that there might be some users who care about this.
Regards,
Jan Kaluza
> As to the "check for sc->server->ssl_alpn_pref->nelts“ that is very much depending on the order of hooks. In the case of mod_h2, registering for alpn happens in pre connection hooks and those run *after* mod_ssl pre_connection hook, I am pretty sure.
>
> //Stefan
>
>> Am 03.06.2015 um 14:52 schrieb Yann Ylavic <yl...@gmail.com>:
>>
>> I wonder if registering the ssl_callback_alpn_select callback
>> inconditionally could break some clients.
>> Are those (ALPN ready) always negociate "http/1.1"?
>>
>> Otherwise we could check for sc->server->ssl_alpn_pref->nelts > 0 (or
>> a dedicated SSLAlpnEnable) beforing using
>> SSL_CTX_set_alpn_select_cb().
>> In that case mod_h2 would not work out of the box, needing some
>> administration on the httpd side.
>>
>>
>> On Wed, Jun 3, 2015 at 12:56 PM, Stefan Eissing
>> <st...@greenbytes.de> wrote:
>>> I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and openssl 1.0.2. All my tests ran fine.
>>>
>>> //Stefan
>>>
>>>> Am 02.06.2015 um 16:56 schrieb Eric Covener <co...@gmail.com>:
>>>>
>>>> Can you test the latest rev of the backport candidate?
>>>>
>>>> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
>>>>
>>>>
>>>>
>>>> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <st...@greenbytes.de> wrote:
>>>>
>>>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>>>>>
>>>>> On 22.04.2015 18:54, Jim Jagielski wrote:
>>>>>>> For me the time seems right to rip NPN out of trunk and only backport
>>>>>>> the ALPN code to 2.4.
>>>>>>>
>>>>>>
>>>>>> I'd be +1 for that.
>>>>>
>>>>> So, to get one step further, and since there were no explicit objections
>>>>> to removing NPN support so far (or arguments for keeping it, FWIW), I
>>>>> went ahead and took a stab at this with r1676004.
>>>>>
>>>>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>>>>> certainly needs more eyes before a backport proposal could be made.
>>>>> There's also a "TODO: we should have a mod_ssl configuration parameter"
>>>>> in ssl_engine_kernel.c which I'm unsure to what it refers.
>>>>
>>>> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed.
>>>>
>>>> I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess.
>>>>
>>>> Stefan
>>>>
>>>>>
>>>>> Kaspar
>>>>
>>>> <green/>bytes GmbH
>>>> Hafenweg 16, 48155 Münster, Germany
>>>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>>>
>>>>
>>>>
>>>
>>> <green/>bytes GmbH
>>> Hafenweg 16, 48155 Münster, Germany
>>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>>
>>>
>>>
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
If a client sends ALPN information in its hello, it certainly can expect an answer from the server. Since in absence of any other modules, the httpd will do „http/1.1“, I think that is a reasonable response.
For clients that do not sent ALPN, any possible answer from the server will not be relevant for them. And I would be surprised if a client gets confused by that. If it uses openssl, it will probably not have registered own callbacks and thus never see the server answer.
As to the "check for sc->server->ssl_alpn_pref->nelts“ that is very much depending on the order of hooks. In the case of mod_h2, registering for alpn happens in pre connection hooks and those run *after* mod_ssl pre_connection hook, I am pretty sure.
//Stefan
> Am 03.06.2015 um 14:52 schrieb Yann Ylavic <yl...@gmail.com>:
>
> I wonder if registering the ssl_callback_alpn_select callback
> inconditionally could break some clients.
> Are those (ALPN ready) always negociate "http/1.1"?
>
> Otherwise we could check for sc->server->ssl_alpn_pref->nelts > 0 (or
> a dedicated SSLAlpnEnable) beforing using
> SSL_CTX_set_alpn_select_cb().
> In that case mod_h2 would not work out of the box, needing some
> administration on the httpd side.
>
>
> On Wed, Jun 3, 2015 at 12:56 PM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and openssl 1.0.2. All my tests ran fine.
>>
>> //Stefan
>>
>>> Am 02.06.2015 um 16:56 schrieb Eric Covener <co...@gmail.com>:
>>>
>>> Can you test the latest rev of the backport candidate?
>>>
>>> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
>>>
>>>
>>>
>>> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <st...@greenbytes.de> wrote:
>>>
>>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>>>>
>>>> On 22.04.2015 18:54, Jim Jagielski wrote:
>>>>>> For me the time seems right to rip NPN out of trunk and only backport
>>>>>> the ALPN code to 2.4.
>>>>>>
>>>>>
>>>>> I'd be +1 for that.
>>>>
>>>> So, to get one step further, and since there were no explicit objections
>>>> to removing NPN support so far (or arguments for keeping it, FWIW), I
>>>> went ahead and took a stab at this with r1676004.
>>>>
>>>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>>>> certainly needs more eyes before a backport proposal could be made.
>>>> There's also a "TODO: we should have a mod_ssl configuration parameter"
>>>> in ssl_engine_kernel.c which I'm unsure to what it refers.
>>>
>>> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed.
>>>
>>> I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess.
>>>
>>> Stefan
>>>
>>>>
>>>> Kaspar
>>>
>>> <green/>bytes GmbH
>>> Hafenweg 16, 48155 Münster, Germany
>>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>>
>>>
>>>
>>
>> <green/>bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>
>>
>>
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: ALPN patch comments
Posted by Yann Ylavic <yl...@gmail.com>.
I wonder if registering the ssl_callback_alpn_select callback
inconditionally could break some clients.
Are those (ALPN ready) always negociate "http/1.1"?
Otherwise we could check for sc->server->ssl_alpn_pref->nelts > 0 (or
a dedicated SSLAlpnEnable) beforing using
SSL_CTX_set_alpn_select_cb().
In that case mod_h2 would not work out of the box, needing some
administration on the httpd side.
On Wed, Jun 3, 2015 at 12:56 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
> I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and openssl 1.0.2. All my tests ran fine.
>
> //Stefan
>
>> Am 02.06.2015 um 16:56 schrieb Eric Covener <co...@gmail.com>:
>>
>> Can you test the latest rev of the backport candidate?
>>
>> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
>>
>>
>>
>> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <st...@greenbytes.de> wrote:
>>
>> > Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>> >
>> > On 22.04.2015 18:54, Jim Jagielski wrote:
>> >>> For me the time seems right to rip NPN out of trunk and only backport
>> >>> the ALPN code to 2.4.
>> >>>
>> >>
>> >> I'd be +1 for that.
>> >
>> > So, to get one step further, and since there were no explicit objections
>> > to removing NPN support so far (or arguments for keeping it, FWIW), I
>> > went ahead and took a stab at this with r1676004.
>> >
>> > Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
>> > certainly needs more eyes before a backport proposal could be made.
>> > There's also a "TODO: we should have a mod_ssl configuration parameter"
>> > in ssl_engine_kernel.c which I'm unsure to what it refers.
>>
>> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed.
>>
>> I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess.
>>
>> Stefan
>>
>> >
>> > Kaspar
>>
>> <green/>bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>
>>
>>
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and openssl 1.0.2. All my tests ran fine.
//Stefan
> Am 02.06.2015 um 16:56 schrieb Eric Covener <co...@gmail.com>:
>
> Can you test the latest rev of the backport candidate?
>
> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
>
>
>
> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <st...@greenbytes.de> wrote:
>
> > Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
> >
> > On 22.04.2015 18:54, Jim Jagielski wrote:
> >>> For me the time seems right to rip NPN out of trunk and only backport
> >>> the ALPN code to 2.4.
> >>>
> >>
> >> I'd be +1 for that.
> >
> > So, to get one step further, and since there were no explicit objections
> > to removing NPN support so far (or arguments for keeping it, FWIW), I
> > went ahead and took a stab at this with r1676004.
> >
> > Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
> > certainly needs more eyes before a backport proposal could be made.
> > There's also a "TODO: we should have a mod_ssl configuration parameter"
> > in ssl_engine_kernel.c which I'm unsure to what it refers.
>
> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed.
>
> I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess.
>
> Stefan
>
> >
> > Kaspar
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: ALPN patch comments
Posted by Eric Covener <co...@gmail.com>.
Can you test the latest rev of the backport candidate?
http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:
>
> > Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
> >
> > On 22.04.2015 18:54, Jim Jagielski wrote:
> >>> For me the time seems right to rip NPN out of trunk and only backport
> >>> the ALPN code to 2.4.
> >>>
> >>
> >> I'd be +1 for that.
> >
> > So, to get one step further, and since there were no explicit objections
> > to removing NPN support so far (or arguments for keeping it, FWIW), I
> > went ahead and took a stab at this with r1676004.
> >
> > Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
> > certainly needs more eyes before a backport proposal could be made.
> > There's also a "TODO: we should have a mod_ssl configuration parameter"
> > in ssl_engine_kernel.c which I'm unsure to what it refers.
>
> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It
> can be removed.
>
> I diff’ed the current mod_ssl against the 2.4 branch, removed everything
> but he ALPN changes and made a patch for my sandbox. This works on my OS X
> with mod_h2. My Ubuntu sandbox is still resisting as some test clients
> still link the system ssl which only speaks NPN (or link against a
> lib_event that links against the system openssl). It’s a mess.
>
> Stefan
>
> >
> > Kaspar
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
>
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <ht...@velox.ch>:
>
> On 22.04.2015 18:54, Jim Jagielski wrote:
>>> For me the time seems right to rip NPN out of trunk and only backport
>>> the ALPN code to 2.4.
>>>
>>
>> I'd be +1 for that.
>
> So, to get one step further, and since there were no explicit objections
> to removing NPN support so far (or arguments for keeping it, FWIW), I
> went ahead and took a stab at this with r1676004.
>
> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
> certainly needs more eyes before a backport proposal could be made.
> There's also a "TODO: we should have a mod_ssl configuration parameter"
> in ssl_engine_kernel.c which I'm unsure to what it refers.
The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed.
I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess.
Stefan
>
> Kaspar
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: ALPN patch comments
Posted by Kaspar Brand <ht...@velox.ch>.
On 22.04.2015 18:54, Jim Jagielski wrote:
>> For me the time seems right to rip NPN out of trunk and only backport
>> the ALPN code to 2.4.
>>
>
> I'd be +1 for that.
So, to get one step further, and since there were no explicit objections
to removing NPN support so far (or arguments for keeping it, FWIW), I
went ahead and took a stab at this with r1676004.
Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it
certainly needs more eyes before a backport proposal could be made.
There's also a "TODO: we should have a mod_ssl configuration parameter"
in ssl_engine_kernel.c which I'm unsure to what it refers.
Kaspar
Re: ALPN patch comments
Posted by Jim Jagielski <ji...@jaguNET.com>.
>
> For me the time seems right to rip NPN out of trunk and only backport
> the ALPN code to 2.4.
>
I'd be +1 for that.
Re: ALPN patch comments
Posted by Kaspar Brand <ht...@velox.ch>.
On 22.04.2015 18:45, Stefan Eissing wrote:
> I understand your argument. My pov is of someone trying to bring
> http/2 to the people. While bringing a new httpd on an existing
> system seems easy, installing a new system openssl is more
> challenging with its dependencies and the changes in hiding non
> public parts of their API.
It doesn't necessarily mean replacing the system OpenSSL version. A
separately built version (static libs only, which is OpenSSL's default)
is fine for mod_ssl - just specify via "./configure --with-ssl=". I
believe Ivan Ristic once had something on it in his blog, it's a fairly
straightforward and painless option for an admin, I think.
Kaspar
Re: ALPN patch comments
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 22.04.2015 um 17:49 schrieb Kaspar Brand <ht...@velox.ch>:
>
>> On 22.04.2015 10:52, Stefan Eissing wrote:
>> I made two small patches based on the feedback from Kaspar. One for
>> the code and one for the documentation.
>
> Thanks. In the patch for ssl_private.h, the complete NPN block should
> actually be dropped - the same block is are already part of
> ssl_private.h, just 10 lines above
Yes. Not my change though. ;-)
>> However there are a lot of openssl 1.0.1 installations out there
>> where httpd 2.4 is deployed which already talk NPN
>
> "a lot of... which already talk NPN"? I have a bit a hard time in
> following this argument: since mod_ssl in 2.4 doesn't have NPN, this
> suggests that these installations currently rely on custom patches in
> any case - so I wouldn't expect there to be "a lot of" (or I might be
> missing the real point)
The openssl 1.0.1 which is out there talks NPN. That's what I meant.
I understand your argument. My pov is of someone trying to bring http/2 to the people. While bringing a new httpd on an existing system seems easy, installing a new system openssl is more challenging with its dependencies and the changes in hiding non public parts of their API.
My original patch was replacing the mod_ssl NPN registration with the ALPN ones, but using the NPN internally when linking against an openssl without ALPN. It was not completely hidden since both work slightly different, though.
Just my €0.02. I will be happy if "just" the ALPN parts make their way into the next 2.4.
//stefan
>> and it might take some time for getting ALPN support from the
>> distros. Which would mean more people building and deploying their
>> own SSL libraries/patching mod_ssl and having no auto update, if they
>> want to use SPDY or HTTP/2.
>
> I don't find this reasoning very convincing... if we look at
> distributions with long term support (which is the sort of thing to
> consider for running a production HTTP server), then we see that they
> are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And
> they usually stay with these versions for the whole OS release lifetime,
> only security fixes are backported (new features only in exceptional
> cases). I.e., it's highly unlikely that admins could rely on the
> vendor-supplied httpd package to get NPN in the next, say, 12 months.
> "auto update" typically means "security fixes only".
>
> OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or
> next year, then I'd say that chances are quite high that he also
> upgrades to OpenSSL 1.0.2 at the same time (in particular given the
> increased pace for new OpenSSL releases and the faster EOL timelines,
> see https://www.openssl.org/about/releasestrat.html).
>
> For me the time seems right to rip NPN out of trunk and only backport
> the ALPN code to 2.4.
>
> Kaspar
Re: ALPN patch comments
Posted by Kaspar Brand <ht...@velox.ch>.
On 22.04.2015 10:52, Stefan Eissing wrote:
> I made two small patches based on the feedback from Kaspar. One for
> the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h, just 10 lines above.
> However there are a lot of openssl 1.0.1 installations out there
> where httpd 2.4 is deployed which already talk NPN
"a lot of... which already talk NPN"? I have a bit a hard time in
following this argument: since mod_ssl in 2.4 doesn't have NPN, this
suggests that these installations currently rely on custom patches in
any case - so I wouldn't expect there to be "a lot of" (or I might be
missing the real point).
> and it might take some time for getting ALPN support from the
> distros. Which would mean more people building and deploying their
> own SSL libraries/patching mod_ssl and having no auto update, if they
> want to use SPDY or HTTP/2.
I don't find this reasoning very convincing... if we look at
distributions with long term support (which is the sort of thing to
consider for running a production HTTP server), then we see that they
are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And
they usually stay with these versions for the whole OS release lifetime,
only security fixes are backported (new features only in exceptional
cases). I.e., it's highly unlikely that admins could rely on the
vendor-supplied httpd package to get NPN in the next, say, 12 months.
"auto update" typically means "security fixes only".
OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or
next year, then I'd say that chances are quite high that he also
upgrades to OpenSSL 1.0.2 at the same time (in particular given the
increased pace for new OpenSSL releases and the faster EOL timelines,
see https://www.openssl.org/about/releasestrat.html).
For me the time seems right to rip NPN out of trunk and only backport
the ALPN code to 2.4.
Kaspar