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



Reply via email to