Re: ALPN patch comments

[Stefan Eissing]

 Am 05.06.2015 um 01:37 schrieb Yann Ylavic ylavic@gmail.com:
 
 On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com 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...

Something like the one below maybe. But this is 2.6/3.0 music. What do we do 
for 2.4?

cheers, Stefan
——
# Listen directives define which transport protocols are active
Listen 443
Listen 1234 ssh

# Protocols lists the ALPN identifiers allowed on connections in preferred order
# ProtocolTransports defaults to the union of transports the server listens to
Protocols h2 spdy/3.1 http/1.1
ProtocolTransports tls ssh clear

# vhosts may limit this down or change order (but not extend it?)
vhost *
  ServerName test1.example.org
  Protocols h2 http/1.1
  ProtocolTransports tls
/vhost
vhost *
  ServerName test2.example.org
  Protocols *
  ProtocolTransports ssh
/vhost

Modules with protocol support need to register the ALPN ids plus a callback at 
core where they become available at the base server? Callbacks  are invoked for 
selected protocol with selected protocol id.

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

Re: ALPN patch comments

[Eric Covener]

On Fri, Jun 5, 2015 at 8:39 AM Stefan Eissing stefan.eiss...@greenbytes.de
wrote:


  Am 05.06.2015 um 01:37 schrieb Yann Ylavic ylavic@gmail.com:
 
  On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com
 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...

 Something like the one below maybe. But this is 2.6/3.0 music. What do we
 do for 2.4?

 cheers, Stefan
 ——
 # Listen directives define which transport protocols are active
 Listen 443
 Listen 1234 ssh

 # Protocols lists the ALPN identifiers allowed on connections in preferred
 order
 # ProtocolTransports defaults to the union of transports the server
 listens to
 Protocols h2 spdy/3.1 http/1.1
 ProtocolTransports tls ssh clear

 # vhosts may limit this down or change order (but not extend it?)
 vhost *
   ServerName test1.example.org
   Protocols h2 http/1.1
   ProtocolTransports tls
 /vhost
 vhost *
   ServerName test2.example.org
   Protocols *
   ProtocolTransports ssh
 /vhost

 Modules with protocol support need to register the ALPN ids plus a
 callback at core where they become available at the base server? Callbacks
 are invoked for selected protocol with selected protocol id.


I think Protocols and moving the registration in the patch to the core is
a good compromise.  If the requirement anyone has interest in working on is
h2 over tls, then at the moment the only effect will be driving the ALPN
negotiation.

Re: ALPN patch comments

[Roy T. Fielding]

 On Jun 4, 2015, at 9:19 AM, Stefan Eissing stefan.eiss...@greenbytes.de 
 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

[Yann Ylavic]

On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com 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

[Yann Ylavic]

On Thu, Jun 4, 2015 at 6:19 PM, Stefan Eissing
stefan.eiss...@greenbytes.de 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

[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 ylavic@gmail.com:
 
 On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic ylavic@gmail.com wrote:
 On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:
 
 
 On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com 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.

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

RE: ALPN patch comments

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

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

[Yann Ylavic]

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 b...@qqmail.nl 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 wr...@rowe-clan.net:

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

[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 ylavic@gmail.com 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 b...@qqmail.nl 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 wr...@rowe-clan.net:
 
 On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing
 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

[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

[Eric Covener]

On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com 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

[Yann Ylavic]

On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:


 On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com 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

[Yann Ylavic]

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 j...@jagunet.com 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 ylavic@gmail.com 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 b...@qqmail.nl 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 wr...@rowe-clan.net:

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

[Yann Ylavic]

On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic ylavic@gmail.com wrote:
 On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:


 On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com 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

[Stefan Eissing]

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

[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 cove...@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.eiss...@greenbytes.de wrote:
 
  Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Yann Ylavic]

On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
stefan.eiss...@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 ylavic@gmail.com:

 Are those (ALPN ready) always negociate http/1.1?

Re: ALPN patch comments

[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 ylavic@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
stefan.eiss...@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 cove...@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.eiss...@greenbytes.de 
wrote:


Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Yann Ylavic]

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

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

[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
stefan.eiss...@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 cove...@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.eiss...@greenbytes.de wrote:

  Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Stefan Eissing]

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 ylavic@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
 stefan.eiss...@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 cove...@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.eiss...@greenbytes.de wrote:
 
 Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Stefan Eissing]

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

 Am 03.06.2015 um 12:56 schrieb Stefan Eissing stefan.eiss...@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 cove...@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.eiss...@greenbytes.de wrote:
 
 Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Yann Ylavic]

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

[Stefan Eissing]

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

[Yann Ylavic]

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
stefan.eiss...@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 ylavic@gmail.com:

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

 --


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

Re: ALPN patch comments

[William A Rowe Jr]

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

[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 
stefan.eiss...@greenbytes.de wrote:


  Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Rainer Jung]

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

[Stefan Eissing]

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 rainer.j...@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

[William A Rowe Jr]

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 httpd-dev.2...@velox.ch
wrote:

 On 27.04.2015 17:04, Stefan Eissing wrote:
  Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Kaspar Brand]

On 27.04.2015 17:04, Stefan Eissing wrote:
 Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Jim Jagielski]

Thank You!!

Will review ASAP.

 On Apr 29, 2015, at 7:05 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 
 On 27.04.2015 17:04, Stefan Eissing wrote:
 Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[Stefan Eissing]

 Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@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

[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.

Kaspar

Re: ALPN patch comments

[Stefan Eissing]

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 httpd-dev.2...@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

[Rainer Jung]

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

[Stefan Eissing]

 Am 22.04.2015 um 17:49 schrieb Kaspar Brand httpd-dev.2...@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

[Jim Jagielski]

 
 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

[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.

 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

Re: ALPN patch comments

[Rainer Jung]

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

[Kaspar Brand]

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

[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.

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