We could possibly move the SNI checks to ssl_hook_Access (where the renegotiation logic is), and return 421 only if a renegotiation is needed (including based on the parameters which cannot be renegotiated, as per the comment around the SNI check if that list is or can be exhaustive, those parameters must be "compatible" with the new vhost). Otherwise, it should be safe to let the request pass in, because we checked that the existing SSLProtocol is compatible, that any existing client authentication is compatible (same CAs and acceptable CAs), ... It may not be an easy task, though.
On Fri, Sep 18, 2015 at 2:22 PM, Stefan Eissing <[email protected]> wrote: > +1. > > I would like it to go further, in case the relevant SSL config is the same > for both hosts, but this looks definitely better than what we have now. Maybe > I'd work on that next week a bit... > >> Am 18.09.2015 um 13:57 schrieb Plüm, Rüdiger, Vodafone Group >> <[email protected]>: >> >> Looks good from a brief view. +1 >> >> Regards >> >> Rüdiger >> >>> -----Ursprüngliche Nachricht----- >>> Von: Yann Ylavic [mailto:[email protected]] >>> Gesendet: Freitag, 18. September 2015 13:24 >>> An: [email protected] >>> Betreff: Re: 2.4.17-protocols-http2/ - SNI issue >>> >>> On Fri, Sep 18, 2015 at 12:56 PM, Stefan Eissing >>> <[email protected]> wrote: >>>> Ok, what is happening for Steffen is not a bug, but a missing feature. >>> The question is how we move forward. >>>> >>>> The certificate at apachelounge.com has a long list of >>> subjectAltNames, probably common for a lot of sites. Chrome opens a >>> connection to server1, established h2, keeps it open. You open a tab on >>> server2, chrome sees the altName on the server1 cert and *reuses* that >>> connection to send the request for server2. >>>> >>>> httpd sees that the request is not in the same vhost as the one >>> belonging to the SNI server1 and refuses to serve it with a 421. Which >>> rfc7540 intended for this, telling the client to use a new connection. >>> >>> IMHO we should not base our check on SNI vs hostname (header Host) but >>> rather r->server vs sslconn->server (ie. handshakeserver), patch >>> attached. >>> >>> What really matters is that the initial handshake was made with the >>> same SSL parameters. >>> >>> Regards, >>> Yann. > > <green/>bytes GmbH > Hafenweg 16, 48155 Münster, Germany > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 > > >
