On 13 Dec 2013, at 06:05, Kaspar Brand <httpd-dev.2...@velox.ch> wrote:
> On 12.12.2013 20:06, William A. Rowe Jr. wrote:
>> On Thu, 12 Dec 2013 09:28:16 +0000 "Plüm, Rüdiger, Vodafone Group"
>> <ruediger.pl...@vodafone.com> wrote:
>>
>> 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, 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.
>
> "completely broken" is a relatively bold statement. As far as I can tell, it
> essentially boils down to the interpretation of the "url" parameter in the
> ProxyPass directive ("a partial URL for the remote server", as the docs
> currently say). In my understanding, in the https:// case, it's a URL for
> which mod_proxy_http should perform TLS name checking (à la RFC 6125), not
> simply a hostname [plus port] for opening an TCP connection and then issuing
> a CONNECT request.
ProxyPass doesn't get used on my forward proxies. This is the case where, e.g.,
your user-agent wants to reach an HTTPS URL via a proxy and so sends, e.g.:
CONNECT remote.host.example:443 HTTP/1.1
Host: remote.host.example
over an HTTPS connection to proxy.example. The configuration for my forward
proxies isn't much different from the example at
http://httpd.apache.org/docs/current/mod/mod_proxy.html#examples
I'm not sure what the TLS SNI hostname should contain but, AIUI, clients would
send "proxy.example". It's not reasonable to expect the proxy server to know
the private key for remote.host.example
--
Tim Bannister – is...@jellybaby.net
