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 Fri, 13 Dec 2013 19:17:40 GMT
On Fri, 13 Dec 2013 07:05:13 +0100
Kaspar Brand <httpd-dev.2013@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.pluem@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.

I will agree, plain-text forward proxy listeners are unaffected, only
https:// listeners are tested for TLS/Host: mismatches.  Also, if the
proxy request refers to a resource on the same proxy host, I suppose
that would also succeed.  Although I can't think of a client which would
attempt that.

Otherwise, yes, https:// forward-proxied requests are entirely broken
by the error test AP02032.

> 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). 

As mentioned by several others, you seem quite confused on this thread.
ProxyPass is orthogonal to forward proxy configurations.  Perhaps you
are mixing up my top post on this subject (of 25 Nov) with the PR 55782?
That report details reverse proxy misbehavior.  This report details
forward proxy misbehavior.  This entire class of defects are rooted in
the TLS/SNI implementation, but *this* forward proxy defect is trivial
to reproduce.

> 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.

Thankfully, the user can toggle the SSLProxyCheckPeerCN behavior.

There is no toggle for the misguided AP 02032 error check behavior,
causing all forward proxy CONNECT requests to fail.

> (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.)

Because AP 02032 causes to the forward proxy server side defect, that
wouldn't get us any closer to restoring forward proxy behavior.


Mime
View raw message