httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: 2.4.17-protocols-http2/ - SNI issue
Date Fri, 18 Sep 2015 12:22:02 GMT
+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 <ruediger.pluem@vodafone.com>:
> 
> Looks good from a brief view. +1
> 
> Regards
> 
> Rüdiger
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Yann Ylavic [mailto:ylavic.dev@gmail.com]
>> Gesendet: Freitag, 18. September 2015 13:24
>> An: dev@httpd.apache.org
>> Betreff: Re: 2.4.17-protocols-http2/ - SNI issue
>> 
>> 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.

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Mime
View raw message