Re: Comments on Explicit/Trusted Proxy

Hi, Werner

Feels weird for me to be arguing for the other side, but…

On May 5, 2013, at 11:39 AM, Werner Baumann <werner.baumann@onlinehome.de> wrote:

> An explicit trusted proxy does not meet this definition of wiretapping
> because of condition 1. Whether information is delivered to a third
> party at all depends on the administration of that proxy. End users will
> have to decide whether to trust it or not (which is much more easy done
> than to decide whether to trust some CA or not).

Corporate proxies are installed by the same IT departments that install the corporate laptops. So why bother the user with pesky warning screens and with installing CA certificates / trusted proxy certificates?  The corporate laptops come pre-installed with the MitM CA. This will not change if some trusted proxy technology is adopted - the user will still "trust" the proxy without their knowledge. 

Ethical IT departments inform their users that this is going on. Certainly in some countries informing the users about this is mandatory. I believe that a trusted proxy scheme is better than the status quo, because browsers *could* display some warning/icon/color in the address bar whenever a proxy is present. However, there is nothing to guarantee that all browser vendors will display such an indication, nor that users would notice if they did.

> All participants in this discussion that argued in favor of explicit
> trusted proxies did it to stop a situation where this is done without
> the end user knowing of the interception. The whole point of these
> proposals is to make the user aware of the proxy and to allow the user
> to either agree or deny.

If you bring your own device, the proxy is visible right now. If you use your employer's device, they are in full control of whether you are or aren't aware.

Yoav

> Start of not trying to insult section:
> Repeating the mantra "Don't open TLS to MITM attacks" is bogus in face
> of the well known fact that TLS is susceptible to MITM attacks
> (mostly due to not trustworthy CAs) and that this weakness is already
> widely exploited.

Received on Sunday, 5 May 2013 12:05:03 UTC