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:
>> The reason is that you can define SSL parameters in Virtual hosts
>> like SSLCiphers or SSLProtocols. If Host header and SNI host match
>> you can be sure that the parameters that you set in the virtual host
>> from which your request is being served have been used. If you allow
>> a mismatch between SNI host and host header you might serve the
>> request on a SSL connection that does not match your SSL parameters
>> set up for the particular virtual host.
>
> 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.
The SNI related changes to the [client] side of mod_ssl for 2.4 (and the
cherrypicked backport to 2.2.25) simply made it more obvious that the
expected effect of ProxyPass statements is probably underspecified when
it is used together with ProxyPreserveHost and/or SSLProxyCheckPeerCN
(with the default for the latter having been changed to On for 2.4).
One way to achieve the "treat the ProxyPass url as a TCP peer for
CONNECT requests" would be the combination outlined in [1], I think.
(The issue you are looking into should be solved on the client-side
code, i.e. primarily in mod_proxy[_http], IMO, although I wouldn't mind
modifications to the server-side part [ssl_hook_ReadReq] either.)
Kaspar
[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201204.mbox/%3C4F8E7873.8000004%40velox.ch%3E
