Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of rainer.jung@kippdata.de
 designates 195.227.30.149 as permitted sender)
Message-ID: <52AF6E36.6020006@kippdata.de>
Date: Mon, 16 Dec 2013 22:18:46 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
References: <20131125155541.66e19919@hub>
	<CAKQ1sVPv86nzsbCk4Cyz-CG2qkhi1ioJwiig-3yLXpUU+=68qg@mail.gmail.com>
	<52943239.9080607@velox.ch>
	<CAKQ1sVNF=RV28cpD7YgET2zpNgpzB2B5tOya3PkL7-ABmqJ57g@mail.gmail.com>
	<CAKQ1sVNuNjes+JptasxBOzrppTatZ6504oHvzcwABCngmkcfZw@mail.gmail.com>
	<20131211171545.2012e83b@hub>	<52A95112.6020702@velox.ch>
	<AB1691BE05AE7F4992697F2A0835627A99182C61@VOEXM10W.internal.vodafone.com>
	<20131212130604.7a9fb904@hub>	<52AAA399.1090505@velox.ch>
	<20131213131740.04933538@hub>	<52AC1125.7090707@velox.ch>
	<20131214023612.43d5c7a2@hub>	<52AC23EC.5090700@velox.ch>
 <20131216132546.4f9741e2@hub>
In-Reply-To: <20131216132546.4f9741e2@hub>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand <httpd-dev.2013@velox.ch> wrote:
> 
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>> ProxyPass is not involved in the SSL forward proxy case at all, as I
>> already tried to point out.
> 
> Good, we've finally agreed.  This entire thread has been on forward
> proxy, so I'm glad you've decided to stop delving into the ProxyPass
> side of this misbehavior.
> 
>> 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. 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). 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).

It seems Firefox does not yet support speaking https to the forward
proxy (https://bugzilla.mozilla.org/show_bug.cgi?id=378637), and chrome
seems to support it
(http://www.chromium.org/developers/design-documents/secure-web-proxy).
i haven't checked the current status in depth though.

Finally: CONNECT over HTTPS wasn't working in our web server for a long
time, see https://issues.apache.org/bugzilla/show_bug.cgi?id=29744.

Regards,

Rainer