httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Tue, 17 Dec 2013 04:29:58 GMT
On Mon, 16 Dec 2013 22:18:46 +0100
Rainer Jung <> wrote:

> On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> > On Sat, 14 Dec 2013 10:25:00 +0100
> > Kaspar Brand <> wrote:
> > 
> >> Just unload mod_proxy_http and mod_ssl
> >> from the configuration, and you'll find that forward proxying
> >> https:// requests continues to work perfectly, i.e. is completely
> >> unaffected by any code in these two modules (mod_proxy_connect is
> >> all it takes)
> > 
> > I'm just wondering two days later if I'm the only one struck by the
> > madness of insisting 'httpd can only do one thing at once', or
> > whether I'm one of many who were too taken aback to respond yet.
> > 
> > One thing httpd has done for years is 'walk and chew gum at the same
> > time', and done it well.
> > 
> > If you are actually arguing for retaining a defect on the basis
> > that it is acceptable to require the user drop modules used by
> > other hosts running in the same process, I'm pretty sure your
> > solution is not acceptable to the pmc of this project.
> > 
> > The user-agent must use an https CONNECT from the user agent to the
> > proxy server (using mod_ssl) lest the entire office/floor/it ops
> > center sniff that traffic off the wire.  Your solution is devoid of
> > any sense of logic or security.
> "must" is a bit strong: AFAIK user agents will not use https to an
> https forward proxy, but instead http plus CONNECT. 

If auth is used, https from the user-agent to the proxy host, and 
https tunneled from the user-agent straight through to the target of
the CONNECT request, provided an https URL for the https protocol
proxy is configured.

> The proxy is a
> man in the middle but should nevertheless not be able to easily
> decrypt the ssl encryption set up between user agent and target
> server (via the packet forwarding proxy). 

Also my understanding.  https: proxy CONNECT would tunnel an entirely
distict ssl session end to end, with the proxy itself having very
little chance of decoding the conversation.

> The like no other sniffing
> system should be. What is noticeable though is the address/name and
> port of the system the user agent wants to connect to (the CONNECT
> data which is send unencrypted to the forward proxy).

Yes, the https target is revealed.  Proxy auth is revealed (often 
dangerously overlapping the user's credentials on other services).

> It seems Firefox does not yet support speaking https to the forward
> proxy (, and
> chrome seems to support it
> (
> i haven't checked the current status in depth though.

Thanks for the data points, collecting a number of additional data
points in the morning.

> Finally: CONNECT over HTTPS wasn't working in our web server for a
> long time, see

I'd been aware of that.

View raw message