RFC 7540 (HTTP/2) wrt reusable connections and SNI

[Yann Ylavic <yl...@gmail.com>]

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

Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI

[Daniel Kahn Gillmor <dk...@fifthhorseman.net>]

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

["Roy T. Fielding" <fi...@gbiv.com>]

> On Jun 9, 2015, at 3:42 AM, Yann Ylavic <yl...@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
> <st...@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

[Yann Ylavic <yl...@gmail.com>]

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
<st...@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 <yl...@gmail.com>:
>>
>> On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing
>> <st...@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

[Stefan Eissing <st...@greenbytes.de>]

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 <yl...@gmail.com>:
> 
> On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing
> <st...@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

[Yann Ylavic <yl...@gmail.com>]

On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing
<st...@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

[Stefan Eissing <st...@greenbytes.de>]

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 <co...@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

[Eric Covener <co...@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