- From: Mike Belshe <mike@belshe.com>
- Date: Mon, 26 Mar 2012 23:22:46 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: "Adrien W. de Croy" <adrien@qbik.com>, Adam Barth <w3c@adambarth.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABaLYCufzW9RrVryJ8roOc-5kEVQjfCJh09-Ont=_q2aSrPXKA@mail.gmail.com>
On Mon, Mar 26, 2012 at 8:02 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > In message <em09ef4353-30f0-4c3a-bd0b-f9912deb7be4@BOMBED>, "Adrien W. de > Croy" > writes: > > >I'm all for using TLS everywhere (apart from the load), but proxies > >need access to raw payload. That requirement isn't going away. > > As bad as the idea might be in philosophical terms, it is a requirement > that must be handled. > > On the other hand, there is an equally strong, if not stronger, > requirement to know for sure that nobody is doing MITM on a session. > > I think a right-ish solution is to have a error-response that informs > the client that proxy-use is mandatory and gives the coordinates > for contacting the proxy. > > The client gets a dialog box and can decide if they want to submit > to the proxys policy, or if they want to postpone their activites > until they can get end-to-end-privacy. > You can't stop SSL by blocking SPDY. Twitter and Google are already 100% SSL. Facebook is moving toward 100% SSL and will be there soon. Those who write proxies that wish to subvert the communications of the user are going to have to get more sophisticated to keep doing what they do today. I'm in favor of the GET https:// and all other forms of explicit proxies (where the user is opted in, or configured in through proxy-auto-config, DHCP, etc). The implicit proxies are on limited future life already, and that has nothing to do with SPDY. Mike > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > >
Received on Monday, 26 March 2012 21:23:15 UTC