subject:"Re\: ALPN patch comments"

On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding  wrote:
>
> Hence, we might need a configurable way to ignore a client's ALPN, though I 
> doubt that
> "SSLalpn off" is the right way to express that.  Likewise, neither is 
> SSLAlpnPreference.
> The server protocol(s) preference should be independent of the 
> session/connection protocol.
> Our internal configuration and use of ALPN should be based on the overall 
> configuration, not a
> configuration specific to the SSL code.  Many configurations won't include 
> ALPN.

Maybe we can reuse the Protocol directive then...

Re: ALPN patch comments

2015-06-04 Thread Roy T. Fielding

> On Jun 4, 2015, at 9:19 AM, Stefan Eissing  
> wrote:
> 
> I think we need to clarify some things:
> 
> 1. ALPN is initiated by the client. When a client does not send ALPN as part 
> of client helo, the SSL alpn callbacks are not invoked and the server does 
> not send any ALPN information back. This is different from NPN.
> 
> 2. SSLAlpnPreference is intended as the final word to make a choice when 
> either one ALPN callback proposes many protocols or of several callbacks 
> propose protocols. So, when mod_spdy and mod_h2 are active *and* the client 
> claims to support spdy/3.1 and h2, the SSLAlpnPreference determines what gets 
> chosen and sent to the client. This was not necessary with NPN as in that SSL 
> extension the client was making the choice.
> 
> 3. Independent of the client proposal, as I read the spec, the server is free 
> to chose any protocol identifier it desires. This might result in the client 
> closing the connection. So, if the client uses ALPN and the server does not 
> want/cannot do/is configured not to support any of the clients proposals, 
> httpd can always send back „http/1.1“ since this is what it always supports.
> 
> In this light, and correct me if I’m wrong, I see no benefit and only 
> potential harm by introducing a „SSLALpn on|off“ configuration directive. I 
> think the current implementation covers all use cases and if one is missing, 
> please point out the scenario.

Ultimately, what we need is a single configuration that defines how the host
will respond to connections.  I suggest that this should be done on a per-vhost 
basis
if SNI is present, or a per-server basis if not.  It should not depend on 
either ALPN
or TLS being present.  This needs to be defined by the server admin, not hard 
coded in
the h2 code.  We should also have a way for the end of a response to reset the 
connection
to a possibly different set of protocols (i.e., Upgrade), but that's an 
independent concern.

Hence, we might need a configurable way to ignore a client's ALPN, though I 
doubt that
"SSLalpn off" is the right way to express that.  Likewise, neither is 
SSLAlpnPreference.
The server protocol(s) preference should be independent of the 
session/connection protocol.
Our internal configuration and use of ALPN should be based on the overall 
configuration, not a
configuration specific to the SSL code.  Many configurations won't include ALPN.

> As with the register once or on every connection optimization, yes, there 
> might be some performance to gain. But I think it is not so straightforward 
> to implement this, as not only the address and port influences this but also 
> the SNI that gets send in the client helo. So, one would have at least to 
> verify that registering an ALPN callback *after* the connection is open and 
> SNI has been received has any effect. 

I would hope that SNI is received before our connection is established (our 
connection is the
virtual session over TLS, not the TCP connection).  There shouldn't be any need 
to mess with
SSL internals within mod_h2.  Otherwise, it will be difficult to support h2c 
and h2 over SSH
with the same code.

Roy

Re: ALPN patch comments

On Thu, Jun 4, 2015 at 6:19 PM, Stefan Eissing
 wrote:
> I think we need to clarify some things:
>
> 1. ALPN is initiated by the client. When a client does not send ALPN as part 
> of client helo, the SSL alpn callbacks are not invoked and the server does 
> not send any ALPN information back. This is different from NPN.

Agreed.

>
> 2. SSLAlpnPreference is intended as the final word to make a choice when 
> either one ALPN callback proposes many protocols or of several callbacks 
> propose protocols.

I may be missing something but this is not how it is implemented.
If the client sends a protocol which is *not* in SSLAlpnPreference,
but only in the ones proposed by the module (mod_h2), this protocol
will still be accepted.
So SSLAlpnPreference does not have the final word, it will make the
choice between the protocols it knows only.

For this to be the case, we would have to exclude httpd's unknown
client_protos from the proposed_protos, i.e.:

Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c(revision 1683271)
+++ modules/ssl/ssl_engine_kernel.c(working copy)
@@ -2242,6 +2234,7 @@ int ssl_callback_alpn_select(SSL *ssl,

 client_protos = apr_array_make(c->pool, 0, sizeof(char *));
 for (i = 0; i < inlen; /**/) {
+const char *proto;
 unsigned int plen = in[i++];
 if (plen + i > inlen) {
 // someone tries to trick us?
@@ -2249,8 +2242,10 @@ int ssl_callback_alpn_select(SSL *ssl,
   "ALPN protocol identifier too long");
 return SSL_TLSEXT_ERR_ALERT_FATAL;
 }
-APR_ARRAY_PUSH(client_protos, char *) =
-apr_pstrndup(c->pool, (const char *)in+i, plen);
+proto = apr_pstrndup(c->pool, (const char *)in+i, plen);
+if (ssl_array_index(ctx->ssl_alpn_pref, proto) >= 0) {
+APR_ARRAY_PUSH(client_protos, char *) = proto;
+}
 i += plen;
 }

--

Otherwise, all the client_protos will be elligible by mod_h2 (only) as
proposed_protos, and the final one be selected with:

+/*
+ * Compare two ALPN protocol proposal. Result is similar to strcmp():
+ * 0 gives same precedence, >0 means proto1 is preferred.
+ */
+static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
+   const char *proto1,
+   const char *proto2)
+{
+if (ctx && ctx->ssl_alpn_pref) {
+int index1 = ssl_array_index(ctx->ssl_alpn_pref, proto1);
+int index2 = ssl_array_index(ctx->ssl_alpn_pref, proto2);
+if (index2 > index1) {
+return (index1 >= 0) ? 1 : -1;
+}
+else if (index1 > index2) {
+return (index2 >= 0) ? -1 : 1;
+}
+}
+/* both have the same index (mabye -1 or no pref configured) and we compare
+ * the names so that spdy3 gets precedence over spdy2. That makes
+ * the outcome at least deterministic. */
+return strcmp((const char *)proto1, (const char *)proto2);
+}

which may bypass SSLAlpnPreference ("-1 or no pref configured").

> So, when mod_spdy and mod_h2 are active *and* the client claims to support 
> spdy/3.1 and h2, the SSLAlpnPreference determines what gets chosen and sent 
> to the client.

Right, provided both are known.


>
> 3. Independent of the client proposal, as I read the spec, the server is free 
> to chose any protocol identifier it desires. This might result in the client 
> closing the connection. So, if the client uses ALPN and the server does not 
> want/cannot do/is configured not to support any of the clients proposals, 
> httpd can always send back „http/1.1“ since this is what it always supports.

Agreed.

>
> In this light, and correct me if I’m wrong, I see no benefit and only 
> potential harm by introducing a „SSLALpn on|off“ configuration directive. I 
> think the current implementation covers all use cases and if one is missing, 
> please point out the scenario.

I also see another issue (already stated in my previous messages): a
client sends an ALPN Hello *without* "http/1.1", mod_h2 is not
configured, the connection is refused.
Unless each ALPN compatible MUST (as per RFC) propose "http/1.1", we
need a way to disable ALPN on httpd.


Regards,
Yann.

Re: ALPN patch comments

2015-06-04 Thread Stefan Eissing

I think we need to clarify some things:

1. ALPN is initiated by the client. When a client does not send ALPN as part of 
client helo, the SSL alpn callbacks are not invoked and the server does not 
send any ALPN information back. This is different from NPN.

2. SSLAlpnPreference is intended as the final word to make a choice when either 
one ALPN callback proposes many protocols or of several callbacks propose 
protocols. So, when mod_spdy and mod_h2 are active *and* the client claims to 
support spdy/3.1 and h2, the SSLAlpnPreference determines what gets chosen and 
sent to the client. This was not necessary with NPN as in that SSL extension 
the client was making the choice.

3. Independent of the client proposal, as I read the spec, the server is free 
to chose any protocol identifier it desires. This might result in the client 
closing the connection. So, if the client uses ALPN and the server does not 
want/cannot do/is configured not to support any of the clients proposals, httpd 
can always send back „http/1.1“ since this is what it always supports.

In this light, and correct me if I’m wrong, I see no benefit and only potential 
harm by introducing a „SSLALpn on|off“ configuration directive. I think the 
current implementation covers all use cases and if one is missing, please point 
out the scenario.

As with the register once or on every connection optimization, yes, there might 
be some performance to gain. But I think it is not so straightforward to 
implement this, as not only the address and port influences this but also the 
SNI that gets send in the client helo. So, one would have at least to verify 
that registering an ALPN callback *after* the connection is open and SNI has 
been received has any effect. 

cheers,

  Stefan

> Am 04.06.2015 um 14:52 schrieb Yann Ylavic :
> 
> On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic  wrote:
>> On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener  wrote:
>>> 
>>> 
>>> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic  wrote:

 I think what makes the thing a bit awkward is that the
 negotiable/preferred ALNP identifiers (protocols) is configurable in
 both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
 The former is only a hint while the latter is the real proposal to the
 client (with the fall back to "http/1.1").

 Maybe it would be cleaner to let the modules register the ALPN
 identifiers (at configure time, with another optional function), and
 get rid of SSLAlpnPreference on mod_ssl side.
 If no identifier is registered, mod_ssl won't register the ALPN
 callback either, so that httpd continues to work without ALPN when not
 needed.

>>> I think we need SSLAlpnPreference any time modules register ALPN protocols,
>>> otherwise the admin has no control over whih is negotiated.  I don't think
>>> we should rip it out.
>> 
>> OK, so it should probably be renammed SSLAlpnIDs or similar, and be
>> more than just a hint when configured (i.e. refuse connection if no
>> client ALPN ID matches).
> 
> I meant fall back to "http/1.1" still, not refuse the connection.

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: ALPN patch comments

On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic  wrote:
> On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener  wrote:
>>
>>
>> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic  wrote:
>>>
>>> I think what makes the thing a bit awkward is that the
>>> negotiable/preferred ALNP identifiers (protocols) is configurable in
>>> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
>>> The former is only a hint while the latter is the real proposal to the
>>> client (with the fall back to "http/1.1").
>>>
>>> Maybe it would be cleaner to let the modules register the ALPN
>>> identifiers (at configure time, with another optional function), and
>>> get rid of SSLAlpnPreference on mod_ssl side.
>>> If no identifier is registered, mod_ssl won't register the ALPN
>>> callback either, so that httpd continues to work without ALPN when not
>>> needed.
>>>
>> I think we need SSLAlpnPreference any time modules register ALPN protocols,
>> otherwise the admin has no control over whih is negotiated.  I don't think
>> we should rip it out.
>
> OK, so it should probably be renammed SSLAlpnIDs or similar, and be
> more than just a hint when configured (i.e. refuse connection if no
> client ALPN ID matches).

I meant fall back to "http/1.1" still, not refuse the connection.

Re: ALPN patch comments

Right, but we can still register our own IDs when httpd will handle
them (with a new directive or by the new module itself).

On Thu, Jun 4, 2015 at 2:26 PM, Jim Jagielski  wrote:
> But certainly there are cases were mod_h2 is NOT part of
> the running system, in which case we still need some way
> to handle ALNP.
>
>> On Jun 4, 2015, at 8:07 AM, Yann Ylavic  wrote:
>>
>> I think what makes the thing a bit awkward is that the
>> negotiable/preferred ALNP identifiers (protocols) is configurable in
>> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
>> The former is only a hint while the latter is the real proposal to the
>> client (with the fall back to "http/1.1").
>>
>> Maybe it would be cleaner to let the modules register the ALPN
>> identifiers (at configure time, with another optional function), and
>> get rid of SSLAlpnPreference on mod_ssl side.
>> If no identifier is registered, mod_ssl won't register the ALPN
>> callback either, so that httpd continues to work without ALPN when not
>> needed.
>>
>> WDYT?
>>
>> On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben  wrote:
>>> 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.eiss...@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 :
>>>
>>> On Wed, Jun 3, 2015 at 8:43 AM, 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“.
>>>
>>>
>>>
>>> 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

On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener  wrote:
>
>
> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic  wrote:
>>
>> I think what makes the thing a bit awkward is that the
>> negotiable/preferred ALNP identifiers (protocols) is configurable in
>> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
>> The former is only a hint while the latter is the real proposal to the
>> client (with the fall back to "http/1.1").
>>
>> Maybe it would be cleaner to let the modules register the ALPN
>> identifiers (at configure time, with another optional function), and
>> get rid of SSLAlpnPreference on mod_ssl side.
>> If no identifier is registered, mod_ssl won't register the ALPN
>> callback either, so that httpd continues to work without ALPN when not
>> needed.
>>
> I think we need SSLAlpnPreference any time modules register ALPN protocols,
> otherwise the admin has no control over whih is negotiated.  I don't think
> we should rip it out.

OK, so it should probably be renammed SSLAlpnIDs or similar, and be
more than just a hint when configured (i.e. refuse connection if no
client ALPN ID matches).
Modules could then, the other way around, retrieve that list with an
optional fn, and do nothing if none matches their aptitude...

Re: ALPN patch comments

2015-06-04 Thread Eric Covener

>
>
>> If no identifier is registered, mod_ssl won't register the ALPN
>> callback either, so that httpd continues to work without ALPN when not
>> needed.
>>
>
>
I do like that from a backport perspective though.

Re: ALPN patch comments

2015-06-04 Thread Eric Covener

On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic  wrote:

> I think what makes the thing a bit awkward is that the
> negotiable/preferred ALNP identifiers (protocols) is configurable in
> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
> The former is only a hint while the latter is the real proposal to the
> client (with the fall back to "http/1.1").
>
> Maybe it would be cleaner to let the modules register the ALPN
> identifiers (at configure time, with another optional function), and
> get rid of SSLAlpnPreference on mod_ssl side.
> If no identifier is registered, mod_ssl won't register the ALPN
> callback either, so that httpd continues to work without ALPN when not
> needed.
>
> I think we need SSLAlpnPreference any time modules register ALPN
protocols, otherwise the admin has no control over whih is negotiated.  I
don't think we should rip it out.

Re: ALPN patch comments

2015-06-04 Thread Jim Jagielski

But certainly there are cases were mod_h2 is NOT part of
the running system, in which case we still need some way
to handle ALNP.

> On Jun 4, 2015, at 8:07 AM, Yann Ylavic  wrote:
> 
> I think what makes the thing a bit awkward is that the
> negotiable/preferred ALNP identifiers (protocols) is configurable in
> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
> The former is only a hint while the latter is the real proposal to the
> client (with the fall back to "http/1.1").
> 
> Maybe it would be cleaner to let the modules register the ALPN
> identifiers (at configure time, with another optional function), and
> get rid of SSLAlpnPreference on mod_ssl side.
> If no identifier is registered, mod_ssl won't register the ALPN
> callback either, so that httpd continues to work without ALPN when not
> needed.
> 
> WDYT?
> 
> On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben  wrote:
>> 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.eiss...@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 :
>> 
>> On Wed, Jun 3, 2015 at 8:43 AM, 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“.
>> 
>> 
>> 
>> 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

I think what makes the thing a bit awkward is that the
negotiable/preferred ALNP identifiers (protocols) is configurable in
both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
The former is only a hint while the latter is the real proposal to the
client (with the fall back to "http/1.1").

Maybe it would be cleaner to let the modules register the ALPN
identifiers (at configure time, with another optional function), and
get rid of SSLAlpnPreference on mod_ssl side.
If no identifier is registered, mod_ssl won't register the ALPN
callback either, so that httpd continues to work without ALPN when not
needed.

WDYT?

On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben  wrote:
> 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.eiss...@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 :
>
> On Wed, Jun 3, 2015 at 8:43 AM, 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“.
>
>
>
> 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

2015-06-04 Thread Bert Huijben

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.eiss...@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 mailto:wr...@rowe-clan.net> >:

On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing mailto:stefan.eiss...@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

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 :
> 
>> On Wed, Jun 3, 2015 at 8:43 AM, 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“.
> 
> 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

2015-06-03 Thread William A Rowe Jr

On Wed, Jun 3, 2015 at 8:43 AM, 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“.
>

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

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
 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 :
>>
>>> On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic  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
>> }
>>
>> --


mod_h2-h2_h2-modssl_register_alpn.patch
Description: application/download

Re: ALPN patch comments

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 :
> 
>> On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic  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

On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic  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

On Wed, Jun 3, 2015 at 3: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“.

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

On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
 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 :
>>
>> Are those (ALPN ready) always negociate "http/1.1"?

Re: ALPN patch comments

2015-06-03 Thread Jan Kaluža

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 :

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
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 :

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
wrote:

Am 25.04.2015 um 11:47 schrieb Kaspar Brand :

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

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: ALPN patch comments

I additionally tested today on Ubuntu 14.04 LTS. Works for me.

> Am 03.06.2015 um 12:56 schrieb Stefan Eissing :
> 
> 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 :
>> 
>> 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 
>>  wrote:
>> 
>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand :
>>> 
>>> 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
>> 
>> bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>> 
>> 
>> 
> 
> bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> 
> 
> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: ALPN patch comments

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 :
> 
> 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
>  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 :
>>> 
>>> 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 
>>>  wrote:
>>> 
 Am 25.04.2015 um 11:47 schrieb Kaspar Brand :

 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
>>> 
>>> bytes GmbH
>>> Hafenweg 16, 48155 Münster, Germany
>>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>> 
>>> 
>>> 
>> 
>> bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>> 
>> 
>> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: ALPN patch comments

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
 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 :
>>
>> 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 
>>  wrote:
>>
>> > Am 25.04.2015 um 11:47 schrieb Kaspar Brand :
>> >
>> > 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
>>
>> bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>
>>
>>
>
> bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>

Re: ALPN patch comments