- 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>
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