httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <httpd-dev.2...@velox.ch>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Tue, 17 Dec 2013 17:33:02 GMT
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 for the record: it wasn't me who brought in references to PR 55782
or PR 54656 into this thread (both of which are about reverse proxying):

https://mail-archives.apache.org/mod_mbox/httpd-dev/201311.mbox/%3CCAKQ1sVPv86nzsbCk4Cyz-CG2qkhi1ioJwiig-3yLXpUU%2B%3D68qg%40mail.gmail.com%3E

https://mail-archives.apache.org/mod_mbox/httpd-dev/201312.mbox/%3C20131211171545.2012e83b%40hub%3E

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

It's fairly far-fetched to make it appear as if I were proposing this as
a "solution", and there isn't any necessity to get personal in this thread.
I was making that statement in the context of illustrating that "ProxyPass
is not involved in the SSL forward proxy case at all".

I will reply to the issue about CONNECT and the relevance of RFC 2817
in a separate message.

Kaspar

Mime
View raw message