- 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