W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Comments on Explicit/Trusted Proxy

From: Adrien W. de Croy <adrien@qbik.com>
Date: Mon, 06 May 2013 10:37:59 +0000
To: "Yoav Nir" <ynir@checkpoint.com>, "Werner Baumann" <werner.baumann@onlinehome.de>
Cc: "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Message-Id: <eme27e61ca-6f5e-4899-8da0-2a3aee58f6d2@bombed>
Hi

------ Original Message ------
From: "Yoav Nir" <ynir@checkpoint.com>
To: "Werner Baumann" <werner.baumann@onlinehome.de>
Cc: "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Sent: 6/05/2013 12:04:26 a.m.
Subject: 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?
Current MiTM schemes require a certificate to be trusted by the client 
in order to avoid incessant cert warnings.

Deployment of this cert is more or less of a headache depending on the 
network environment and client OS.  For instance in a Windows AD, they 
can be pushed out to domain members by Group Policy.

However, enforcement of interception for computers/devices not directly 
under the administative control of the organisation/IT department (e.g. 
phones, or visitors' devices) remains a problem.

In the end, whether the reasons for wanting to intercept an inspect 
https traffic are bogus or not according to us is moot.  Customers will 
go where they are served.  Any proxy (forward) vendor who does not 
currently support https inspection, or doesn't have a plan for it, has 
IMO numbered days.

If all the proxy vendors banded together and refused to provide https 
inspection it wouldn't be a problem. But that's not the case, and to not 
offer it is increasingly (yes the problem is growing) IMO a serious 
competitive disadvantage.  Customers simply don't care.  They want to:

* enforce DLP policy
* scan for malware / malsites at the perimeter
* cache
* content filter

When it was only banks using SSL it wasn't a problem - customers didn't 
really care about not being able to scan bank traffic.  Facebook made it 
a problem for everyone.  The more big sites move to SSL the worse it 
gets.

I hear arguments that standardising MiTM will open the door for illicit 
and clandestine eavesdropping or worse.  However, how do the external 
parties get you to install the trusted root cert?  Or does this claim 
rely on users ignoring cert warnings?  How is this any worse than the 
current situation?

Being able to advertise your presence (as an https-inspecting proxy) is 
surely better than the current scenario.  What would be better still is 
a way for an organisation to enforce use of a proxy, esp for visiting 
devices.  To be able to intercept, and divert to something that can

a) spell out the company policy for use of its internet resources
b) provide a painless way for the browser or other agent to be 
configured to use the proxy (if desired by the user) in accordance with 
the policy.

Currently it's not even possible to display a page instead of the 
requested (https) destination in the case where the client is not 
configured to use a proxy, and doesn't have the proxy spoofing cert 
installed.  Not at least without a browser cert warning.  You get 2 
choices:

1. browser cert warning when you
- intercept the connection
- look at requested server, or connect to destination and obtain actual 
cert
- spoof the cert
- TLS handshake with the client using that cert -> cert warning
- send the page

2. Disconnect the client if it goes somewhere it's not authorized to.  
This leads to in general lousy user experience and support calls.

So, we don't want to do anything about this?  The problem isn't going 
away, and more MiTM implementations are being deployed.  It's the user 
that suffers in the end if we don't act to improve things for them.

Cheers

Adrien

>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 Monday, 6 May 2013 10:38:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC