Re: ALPN patch comments
On Fri, Jun 5, 2015 at 8:39 AM Stefan Eissing wrote: > > > Am 05.06.2015 um 01:37 schrieb Yann Ylavic : > > > > 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... > > 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?) > > ServerName test1.example.org > Protocols h2 http/1.1 > ProtocolTransports tls > > > ServerName test2.example.org > Protocols * > ProtocolTransports ssh > > > 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
> Am 05.06.2015 um 01:37 schrieb Yann Ylavic : > > 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... 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?) ServerName test1.example.org Protocols h2 http/1.1 ProtocolTransports tls ServerName test2.example.org Protocols * ProtocolTransports ssh 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. bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
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
> 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
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
> > >> 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
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
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
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
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
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 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 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
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
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 : > > > > 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
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 : > > 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 bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: ALPN patch comments
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
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 wrote: > On 27.04.2015 17:04, Stefan Eissing wrote: > >> Am 25.04.2015 um 11:47 schrieb Kaspar Brand : > >> 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
Thank You!! Will review ASAP. > On Apr 29, 2015, at 7:05 AM, Kaspar Brand wrote: > > On 27.04.2015 17:04, Stefan Eissing wrote: >>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand : >>> 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
On 27.04.2015 17:04, Stefan Eissing wrote: >> Am 25.04.2015 um 11:47 schrieb Kaspar Brand : >> 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
> 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
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
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
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 : > >> 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
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
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
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
> > 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
> 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 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
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