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.
