httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Sylvester <>
Subject Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Thu, 12 Dec 2013 07:46:32 GMT
On 12/12/2013 12:15 AM, William A. Rowe Jr. wrote:
> On Tue, 26 Nov 2013 09:47:44 +0100
> Yann Ylavic <> wrote:
>> On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic <>
>> wrote:
>>> On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
>>> <>wrote:
>>>> On 26.11.2013 00:46, Yann Ylavic wrote:
>>>>>> Ideas for the appropriate patch to httpd?  Scope this fix to
>>>>>> CONNECT requests alone, or all forward proxy requests?
>>>>> Maybe all forward proxy modules are concerned.
>>>>> There is PR 55782
>>>>>   which I started to debug but did not finish (run out of time).
>>>>>  From there it looked like ProxyPassPreserveHost may cause
>>>>> problems too with SNI (not sure yet).
> Also, 54656.
>>>>> Anyway, shouldn't the proxy code(s) use the Host header to fill
>>>>> in the
>>>> SNI
>>>>> from r->headers_in (when applicable), instead of r->hostname, at
>>>>> least
>>>> for
>>>>> the CONNECT and ProxyPassPreserveHost cases?
>>>> AFAICT, this was the idea in the original patch for PR 53134, but a
>>>> "slightly different approach" was then committed (r1333969).
>>>> As far as PR 55782 is concerned, the problem might be that
>>>> proxy_util.c:ap_proxy_determine_connection() does not take Host:
>>>> header differences into account when checking if an existing
>>>> connection can be reused (not sure). With SNI this would have the
>>>> effect that the hostname from the TLS handshake is causing the
>>>> mismatch with the Host: header.
>>> ap_proxy_determine_connection() should only care about IP:port
>>> reuse, which can be even if the Host has changed.
>> Oh wait, you are probably right here, the IP:port cannot be reused if
>> the Host has changed with SNI, sorry for the noise...
> Right :)
>> Using the Host as SNI at first (handshake) for
>> CONNECT/ProxyPreserveHost/subrequests (at least) is still the way to
>> go, IMHO.
> Yes, that initial SNI Host -> vhost -> SSL negotiation is all correct
> and get us to the appropriate configuration of ssl keys and certs for
> the SNI connection's host target.
It gets to the target whether the conf is appropriate or not :-)
> 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.
this part was always a bit strange: the initial idea was: When the code
sees the Host: and when there was no sni, to force a renegotiation
with the right cert/key.

best regards

View raw message