httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Fri, 13 Dec 2013 09:46:43 GMT

William A. Rowe Jr. wrote:
> On Thu, 12 Dec 2013 09:28:16 +0000
> "Plüm, Rüdiger, Vodafone Group" <> wrote:
>>> -----Original Message-----
>>> From: Kaspar Brand []
>>> Sent: Donnerstag, 12. Dezember 2013 07:01
>>> To:
>>> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT
>>> requests
>>> On 12.12.2013 00:15, William A. Rowe Jr. wrote:
>>>> The rest of the SNI hostname processing steps are where the
>>>> problem lies.  We still need to perform http headers -> vhost
>>>> translation after the connection is established.  If there's any
>>>> desire to do SNI hostname validation, that has to be limited to
>>>> comparing that hostname to the ServerName/ServerAlias entries,
>>>> not to the HTTP Host: which has a different semantic meaning and
>>>> is the only hostname of interest to httpd as an HTTP server.
>>> The logic in ssl_hook_ReadReq was added with r757373. It wasn't in
>>> the initial version of the patch for SNI support (r606190). I
>>> didn't find prior discussion of r757373 on the mailing list, but
>>> perhaps it was motivated by this statement in RFC 6066 (RFC 4366 at
>>> the time):
>>>                                             If the server_name is
>>>    established in the TLS session handshake, the client SHOULD NOT
>>>    attempt to request a different server name at the application
>>> layer.
>>> I never really understood the reasoning for turning this into a
>>> "reject requests if the SNI extension and the Host header
>>> differ" (see e.g. [1],
>> The reason is that you can define SSL parameters in Virtual hosts
>> like SSLCiphers or SSLProtocols. If Host header and SNI host match
>> you can be sure that the parameters that you set in the virtual host
>> from which your request is being served have been used. If you allow
>> a mismatch between SNI host and host header you might serve the
>> request on a SSL connection that does not match your SSL parameters
>> set up for the particular virtual host.
> Yes, and?  Why would this differ from the historical handling of the
> Host: header?  The HTTP Host header is not the dns name of this hop,

It doesn't, but we clearly stated in the docs before: Don't use name based virtual
hosting with SSL for exactly this reasons.

> but the hostname component of the uri.  This logic has completely
> broken forward proxies in httpd on the 2.4 and 2.2.25 releases.

How does this break forward proxies? Usually you connect to a forward proxy via HTTP.
How does SNI matter here?

> The SSL settings come from first the IP/port search, then the resolved
> SNI hostname's vhost, and finally from the corresponding Host: named
> vhost where applicable.  Of course the Host: vhost config may override
> the SNI hostname vhost, that's the correct httpd behavior, just as 
> changing SSL options within a <location > block overrides the vhost.

But these SSL options are not applied later. So if you have two virtual hosts:

NameVirtualHost someip:443

<virtualhost someip:443>
Servername strong
SSLCiphersuite something strong

<virtualhost someip:443>
Servername weak
SSLCiphersuite something weak

Then you would be able to connect to the strong virtual host with a weak cipher just by supplying
'weak' in SNI and
'strong' in the host header.



View raw message