On Tue, Dec 17, 2013 at 5:44 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > > On Mon, 16 Dec 2013 22:29:39 -0600 > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote: > > > My defect is really very simple, Here's a request to proxy.example.com > > created in order to tunnel an https connection to server.example.com; > > > > CONNECT server.example.com:443 HTTP/1.1 > > Host: server.example.com:443 > > Proxy-Authorization: basic aGVsbG86d29ybGQ= > > > > In this case, the admin wants no other network user to share the same > > auth identity, therefore the server-to-proxy connection is https://. > > > > In receiving the request, server.example.com != proxy.example.com and > > things fall apart. The defect is really that simple to describe.
This occurs only in the case where CONNECT over SSL is used (which is not so widespread, since SSL tunneling clients only seem to support this), as opposed to CONNECT on a plain TCP connection through mod_proxy_connect to a backend (which is used by most/all? browsers, to forward any stream --SSL or not-- between the client and the origin server). Since CONNECT over SSL is handled by mod_proxy_connect (r813178, following PR29744), httpd should also make it work with SNI, IMHO https://issues.apache.org/bugzilla/show_bug.cgi?id=29744#c141 is still such (legitimate) case of CONNECT over SSL which won't work without your patch. I also agree with you that SNI can hardly always be mapped to Host: without the possibility to use an IP address and/or a port (both legitimate Host: parts). So I'm +1 with your patch, though it would be nice if SSLStrictSNIVhostCheck could default to "on" for IP-based vhosts and named-based vhosts *all* listenning on port 443, except when ProxyRequests is "on"... I don't know if it's feasible at all (since at least mod_rewrite can change all that at runtime), but these are typical cases for enforcing strict SNI (when provided by the client). > > The defect is actually a little more insideous. If you toggle the Host > to break RFC2616's definition, and use the proxy.example.com identity > instead, the end result will be the same - it will still mismatch and > report that the SNI host should have matched server.example.com. That > is even true when connecting non-ssl to server.example.com:80. > > If the hostname header value was already transposed from the user-agent > request headers into a proxy request headers at the time that test > occurs then we might have a more complex problem. I think the same apply for forward proxy (not CONNECT), ie : GET http(s)://server.example.com/ HTTP/1.1 Host: proxy.example.com The latter is simply ignored. Regards, Yann.
