httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: 2.4.17-protocols-http2/ - SNI issue
Date Fri, 18 Sep 2015 11:23:40 GMT
On Fri, Sep 18, 2015 at 12:56 PM, Stefan Eissing
<stefan.eissing@greenbytes.de> 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.

Mime
View raw message