Discussion started here: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0345.html The whole thread is here: http://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/thread.html
What it currently drifts to is that clients that trigger renegotiation on a h2 connection should be pushed by to HTTP/1.1. There is a specific error code for this. That would be applicable for *all* kinds of TLS renegotiations, from the first request onwards on h2. The question then is how we best let other modules stop ssl_hook_Access() from performing the renegotiation. It may then return HTTP_FORBIDDEN. Then denying hook could store context information in r->notes so that the request is answered specific to the protocols need. Another hook in core which ssl_hook_Access() then triggers? //Stefan > ssl_hook_Access() > Am 22.09.2015 um 15:20 schrieb Yann Ylavic <[email protected]>: > > On Tue, Sep 22, 2015 at 1:24 PM, Stefan Eissing > <[email protected]> wrote: >> >> SSL renegotiation is forbidden in HTTP/2, exactly due to concurrency issues. > > Certainly a concurrency between each one's privacy and every one's > data in the same stream :) > Also, let servers trust the security of the client/proxy side... > >> There is a debate currently on the http-wg mailing list, what to do about >> it, especially for sites that use client certificates. > > They should probably forbid client certificates too :p > > (BTW, could you provide some links please?) > >> >> As Apache httpd, we can at the moment only advise server administrators to >> not enable HTTP/2 for servers/vhosts that make use of renegotiations. > > How can the server know which request a client will issue next on the > same connection, same vhost? same path? > That would be a warning about using multiple vhosts with different SSL > parameters/certificates/... in httpd.conf. > >> We should probably log an error when ap_get_protocol() != "http/1.1", when >> renegotiation is attempted. Anyone know the best place to put that? > > That's probably in ssl_hook_Access() when renegotiate && > !renegotiate_quick => before we SSL_do_handshake(). > >> >> ssl_hook_Access() seems the renegotiation monster. Not sure if I want to >> stick my fingers in there. But this seems to be the place to check the >> protocol and make a log error (at least)? Or do we make a >> connection_param_renegotiate hook that can stop renegotiation and set the >> proper response on the request? > > I think we should add more checks here about the current-server's > parameters vs the handshake-server's ones. > Is the handshaken protocol compatible with the current server's ones > (SSL_METHOD)? > Do the current-server's certificate's SN/SAN(s) include the requested Host? > Are the current's and handshake's SSLVerify equal, with the same CA[DN]s? > ...??? > > Otherwise (or if a renegotiation is required in HTTP/2), bail out with 421. > This should work whenever the parameters/certificates are > shared/compatible between vhosts, putting the bargain at the admin. > > Regards, > Yann. <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
