Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
On Tue 2015-06-09 13:43:59 -0400, Roy T. Fielding wrote: WRT renegotiation, it is fair to say that the WG punted on the idea due to lack of time. If someone figures out a way to safely renegotiate an h2 connection (and all of its streams), then go ahead and implement it, describe it in an I-D, and submit it to the httpbis WG. There is nothing wrong with Apache leading by example. As a heads-up: in the TLS WG, we are strongly considering banning renegotiation altogether in TLS 1.3. We are working on an alternate mechanism for clients that need to re-authenticate after having requested a a resource over an unauthenticated channel, but it will probably not be a full TLS renegotiation. --dkg
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Also from RFC 7540, 9.2.1 A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ (Once the h2 session is established, renegotiation may appear before that.) This is all a result of the „securing the web“ thinking where now HTTP and TLS requirements get interwoven and layers are mixed. sarcasm Security by mixing layers, how ironic! Surely HTTP/2 will secure those who want to share private and valuable informations (secretly), as to the web... It could have been that, though. /sarcasm PS: nothing personal Stefan, just about the new protocol I'm trying to digest...
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
Btw. I have the first report from a user that gets 400 answers in browsers when mod_h2 is active because the browser reused the connection for another host. Also from RFC 7540, 9.2.1 A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ (Once the h2 session is established, renegotiation may appear before that.) This is all a result of the „securing the web“ thinking where now HTTP and TLS requirements get interwoven and layers are mixed. Which means for httpd that mod_ssl and mod_h2 need to talk to each other more. So, when a vhost allows all kinds of renegotiations / parameters, that should be fine and continue being useful when the connection talks HTTP/1. But when h2 is active, some sort of policy restriction needs to be applied (to make it fully standard compliant). Any ideas how to tackle this are appreciated. Am 08.06.2015 um 15:56 schrieb Eric Covener cove...@gmail.com: What's the point of SNI if it can be used to select the correct vhost before the handshake (modulo the port...), but TLS must possibly be renegotiated later for subsequent requests? In configs that use separate certificates, it gets you the correct one, and these are n/a to the coalescing problem In configs that use the same certificate, I guess it gets you slightly different TLS parameters. If you use HTTP/2, you'll have to forego these and per-dir renegotiations. Maybe the latter should just be deprecated, it seems like they cause constant problems green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
Yann, I am with you and feel at least unease about this mixing. But the RFC has been approved and browsers will adhere to it. So if we do not enforce some policies in the server, connections will fail for mysterious reasons. And tickets will be raised... Am 09.06.2015 um 12:06 schrieb Yann Ylavic ylavic@gmail.com: On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Also from RFC 7540, 9.2.1 A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ (Once the h2 session is established, renegotiation may appear before that.) This is all a result of the „securing the web“ thinking where now HTTP and TLS requirements get interwoven and layers are mixed. sarcasm Security by mixing layers, how ironic! Surely HTTP/2 will secure those who want to share private and valuable informations (secretly), as to the web... It could have been that, though. /sarcasm PS: nothing personal Stefan, just about the new protocol I'm trying to digest... green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
It just needed to get out :) But I agree that since we are to implement the RFC, we must comply, and find a way to still comply with HTTP/1. Both checks on SNI and renegotiation occur in the post_read_request hook, so we should be able to deal with vhost's parameters (configured Protocols, ProtocolTransports...), and do the right thing. On Tue, Jun 9, 2015 at 12:09 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Yann, I am with you and feel at least unease about this mixing. But the RFC has been approved and browsers will adhere to it. So if we do not enforce some policies in the server, connections will fail for mysterious reasons. And tickets will be raised... Am 09.06.2015 um 12:06 schrieb Yann Ylavic ylavic@gmail.com: On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Also from RFC 7540, 9.2.1 A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ (Once the h2 session is established, renegotiation may appear before that.) This is all a result of the „securing the web“ thinking where now HTTP and TLS requirements get interwoven and layers are mixed. sarcasm Security by mixing layers, how ironic! Surely HTTP/2 will secure those who want to share private and valuable informations (secretly), as to the web... It could have been that, though. /sarcasm PS: nothing personal Stefan, just about the new protocol I'm trying to digest... green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
On Jun 9, 2015, at 3:42 AM, Yann Ylavic ylavic@gmail.com wrote: It just needed to get out :) But I agree that since we are to implement the RFC, we must comply, and find a way to still comply with HTTP/1. Both checks on SNI and renegotiation occur in the post_read_request hook, so we should be able to deal with vhost's parameters (configured Protocols, ProtocolTransports...), and do the right thing. On Tue, Jun 9, 2015 at 12:09 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Yann, I am with you and feel at least unease about this mixing. But the RFC has been approved and browsers will adhere to it. So if we do not enforce some policies in the server, connections will fail for mysterious reasons. And tickets will be raised... Well, don't be too hasty. There are a number of requirements in the RFC that have nothing to do with HTTP and should be summarily ignored in the core implementation. There are other requirements in the RFC that might turn out to be wrong or unnecessary, just as we found in RFC2068, and it is our task to implement what works and change the RFCs later. However, the server as a whole should be configurable to be compliant (by default) in the relevant code. All of the requirements around TLS, for example, need to be available in the SSL configs, but it is not h2's responsibility to ensure that it has an RFC7540-compliant TLS config. That is the admin's responsibility/choice. WRT renegotiation, it is fair to say that the WG punted on the idea due to lack of time. If someone figures out a way to safely renegotiate an h2 connection (and all of its streams), then go ahead and implement it, describe it in an I-D, and submit it to the httpbis WG. There is nothing wrong with Apache leading by example. Cheers, Roy
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
What's the point of SNI if it can be used to select the correct vhost before the handshake (modulo the port...), but TLS must possibly be renegotiated later for subsequent requests? In configs that use separate certificates, it gets you the correct one, and these are n/a to the coalescing problem In configs that use the same certificate, I guess it gets you slightly different TLS parameters. If you use HTTP/2, you'll have to forego these and per-dir renegotiations. Maybe the latter should just be deprecated, it seems like they cause constant problems
RFC 7540 (HTTP/2) wrt reusable connections and SNI
It was raised by Stefan Eissing in [1] that HTTP/2 (not surprisingly)
encourages UA/clients to reuse established connections even for
differents hostnames, provided they resolve to the same IP address
and wildcard certs or matching alternate names in the certificate to
match.
This obviously is not compatible with our strict checking of the SNI
against the Host header...
And I also fail to see how this will help servers with different
(configured) SSL parameters (like SSLProtocol,
SSLVerify{Client,Depth}, SSLCA*, ...), some of which cannot be
renegotiated due to current limitations in OpenSSL according to the
comment in the corresponding mod_ssl code.
What's the point of SNI if it can be used to select the correct vhost
before the handshake (modulo the port...), but TLS must possibly be
renegotiated later for subsequent requests??
Thoughts?
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58007#c9
