- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 11 Dec 2013 10:29:06 +1300
- To: ietf-http-wg@w3.org
On 2013-12-11 06:59, Peter Lepeska wrote: > Yoav, > > Good summary of conflicting incentives. I think the key is that eproxy > needs to represent a security improvement. Going from MITM to eproxy > should > be seen as going from the insecure 1.x MITM way to do encrypted > proxying to > the 2.x more secure way to do it. There is one extremely simple measure which I and many in the proxy user community have been campaigning for some time now. This is one of the use-cases for MITM which is being deployed *only* because ccertain configuration options are missing from browsers: * MITM all port 80 traffic from clients * 3xx redirect all http:// URLs to https:// * MITM port 443 traffic from clients * un-map https:// URL back to http:// for WAN connection. Sounds daft reason encrypting LAN connections while WAN ones are un-encrypted, but this meets corporates policies in places and there is potential that the encryption can also be extended by the proxy over untrusted networks to a remote POP before the decryption is needed. Please lets kill this use-case before it becomes more popular. It seems to be a trivial and reasonable request for browsers to attempt to use TLS when talking to a proxy. No padlocks or user feedback mechanisms necessary - its not offering user-relevant security but *network* security. Simply extend the proxy config dialog/options to {hostname, port, TLS Y/N tickbox, button to upload cert for the proxy verification} is all the UI required (if any). Yet the amount of pushback on implementing that simple security enhancement is enormous. All the talk of complexity implementing UI feedback sounds like FUD obscuring the detail that this is a small incremental step that could be taken yesterday to improve security. So what if the proxy TLS connection is decrypted at the proxy? there is no guarantee of e2e security here and UI should absolutely not be telling the user green-padlock style stuff about this. Uploading a specific cert for validating the proxy *and only connections to that proxy* allows the browser to indicate when MITM is happening between them. If it works the TLS is invisible, if MITM is detected *that* can be announced, if it fails for other reasons alternatives should be taken without bothering the user. Amos
Received on Tuesday, 10 December 2013 21:29:30 UTC