Re: Comments on Explicit/Trusted Proxy

Hi

On May 6, 2013, at 1:37 PM, "Adrien W. de Croy" <adrien@qbik.com>
 wrote:

> 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

You're preaching to the choir here. I work for a vendor of such proxies, and I'm a co-author of Dave McGrew's draft. I'm just saying that we should not exaggerate the benefit to the user of having an explicitly trusted proxy vs an explicitly trusted CA certificate.

Yoav

Received on Monday, 6 May 2013 11:01:29 UTC