httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Wed, 11 Dec 2013 23:15:45 GMT
On Tue, 26 Nov 2013 09:47:44 +0100
Yann Ylavic <ylavic.dev@gmail.com> wrote:

> On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic <ylavic.dev@gmail.com>
> wrote:
> 
> > On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
> > <httpd-dev.2013@velox.ch>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.

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.



Mime
View raw message