- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 5 Dec 2015 11:38:48 +0100
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
Hi Pat! On Sat, Dec 05, 2015 at 11:23:53AM +0100, Patrick McManus wrote: > Firefox "proxy over https" support was released in October 2014; Chrome > beat us to it. I've heard microsoft banter on the topic, but I'm not sure > if it is currently available. In both browsers you can do h1/h2/spdy over > that link - including mux'd connect tunnels within one h2/spdy session to > the proxy with proxies that support h2/spdy This has some really nice TCP > side-effects when done over poor links. Still waiting for several proxies > to pick up that feature. (that game works both ways :)..) Really cool! I know a number of people who will be quite interested, I'll pass the message. I know some places where it will make a stop to the awful cookie redirect dance. And this is a situation where there's no fear for breaking non-browser devices since they already don't work :-) > UI is done via PAC (which can be done without an external PAC file fwiw) in > both browsers. Yes I remember William explaining this for Chrome a while ago. That seems reasonable for environments where https proxies matter. > I think we will probably add a checkbox for it when we > update that configuration screen (For which I have a different reason to > schedule work anyhow, so this can piggyback). > > But of course, this just authenticates the proxy and secures the transport > to it - It's already critically important to "unbreak" many places playing the redirect dance. > it does not trust the proxy with https data split browser style. I > find it hard to imagine doing so would be in the best interest of our > users. Third parties that would like to be part of that conversation will > assert opportunity cost or just authority and disagree with my opinion. > cest la vie. That's fine and it *must not* trust that proxy by default. User expects the connection to be terminated by the browser (or the local malware but let's not make things complicated) and we'll need to work on the "GET https://" ideas to see how we can offer that control to the user to be allowed to go out in controlled environments. Willy
Received on Saturday, 5 December 2015 10:39:15 UTC