On Mon, Nov 25, 2013 at 10:55 PM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:
> It appears that our SNI hostname comparison is invalid for forward proxy > applications, specifically proxy CONNECT. RFC 2616 states; > > 14.23 Host > > The Host request-header field specifies the Internet host and port > number of the resource being requested, as obtained from the original > URI given by the user or referring resource (generally an HTTP URL, > as described in section 3.2.2). The Host field value MUST represent > the naming authority of the origin server or gateway given by the > original URL. This allows the origin server or gateway to > differentiate between internally-ambiguous URLs, such as the root "/" > URL of a server for multiple host names on a single IP address. > > I had read this as proxy host's name in forward proxy applications, but > reading on, it's clear this is ambiguous; from RFC 2817 > > 5.2 Requesting a Tunnel with CONNECT > > A CONNECT method requests that a proxy establish a tunnel connection > on its behalf. The Request-URI portion of the Request-Line is always > an 'authority' as defined by URI Generic Syntax [2], which is to say > the host name and port number destination of the requested connection > separated by a colon: > > CONNECT server.example.com:80 HTTP/1.1 > Host: server.example.com:80 > > So we have a clear, RFC-approved example of using the final endpoint as > the Host: header value, not the intermediate proxy.example.com. > > In this case, we fail the request because the SNI of the proxy machine > does not match the Host: of the origin server name. > > 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?
