- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 7 Aug 2012 08:20:54 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, Aug 07, 2012 at 06:13:14AM +0000, Poul-Henning Kamp wrote: > In message <0697836F-C4AD-4D89-AB5E-2C83B16A91AF@mnot.net>, Mark Nottingham wri > tes: > > >It's a really big logical leap from the existence of an attack to > >changing the fundamental semantics of the URI scheme. And, that's what a > >MITM proxy is -- it's not legitimate, it's not a recognised role, it's > >an attack. We shouldn't legitimise it. > > As I have said earlier: Many of these deployments have grounds in > valid legal requirements, and they only happen to become MITM because > the TLS protocol offers no other alternative. > > The problem is that TLS does not offer support intermediaries, and people > work around that lack of support when the law says they must. TLS is not really the issue here, it's just HTTPS which is the issue. Having a TLS connection between the client and the proxy with mutual auth provides better protection than what we have right now. It really protects against MITM between the client and the proxy and even better protects user privacy on the LAN than what CONNECT does, since there is no URL nor SNI anymore transported in clear (neither password BTW). If I had the choice, I would always use TLS to connect to my proxy and would allow content inspection for all sites except a bunch of ones I wouldn't trust the platform/admin enough to risk my credentials being stolen (bank/paypal mainly). Willy
Received on Tuesday, 7 August 2012 06:21:22 UTC