On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand <httpd-dev.2...@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). >> > >> > 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... Using the Host as SNI at first (handshake) for CONNECT/ProxyPreserveHost/subrequests (at least) is still the way to go, IMHO.
