httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: 2.4.17-protocols-http2/ - SNI issue
Date Fri, 18 Sep 2015 15:35:40 GMT
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
<> 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
>> Am 18.09.2015 um 13:57 schrieb Plüm, Rüdiger, Vodafone Group <>:
>> Looks good from a brief view. +1
>> Regards
>> Rüdiger
>>> -----Ursprüngliche Nachricht-----
>>> Von: Yann Ylavic []
>>> Gesendet: Freitag, 18. September 2015 13:24
>>> An:
>>> Betreff: Re: 2.4.17-protocols-http2/ - SNI issue
>>> On Fri, Sep 18, 2015 at 12:56 PM, Stefan Eissing
>>> <> 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 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

View raw message