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.

Reply via email to