On Mon, 16 Dec 2013 22:18:46 +0100 Rainer Jung <rainer.j...@kippdata.de> wrote:
> On 16.12.2013 20:25, William A. Rowe Jr. wrote: > > On Sat, 14 Dec 2013 10:25:00 +0100 > > Kaspar Brand <httpd-dev.2...@velox.ch> 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 (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. 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 > https://issues.apache.org/bugzilla/show_bug.cgi?id=29744. I'd been aware of that.
