Re: Comments on Explicit/Trusted Proxy

"Adrien W. de Croy" <> Mon, 06 May 2013 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53BDF21F9283 for <>; Mon, 6 May 2013 16:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C092iQEl44Qd for <>; Mon, 6 May 2013 16:31:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB60C21F92CB for <>; Mon, 6 May 2013 16:31:54 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UZUrF-0006Ee-FN for; Mon, 06 May 2013 23:30:13 +0000
Resent-Date: Mon, 06 May 2013 23:30:13 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UZUr1-00034P-9b for; Mon, 06 May 2013 23:29:59 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UZUqz-0002BG-L0 for; Mon, 06 May 2013 23:29:59 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v8.0.0 (Build 4550)) with SMTP id <>; Tue, 07 May 2013 11:29:29 +1200
From: "Adrien W. de Croy" <>
To: Yoav Nir <>
Cc: Werner Baumann <>, "<>" <>
Date: Mon, 06 May 2013 23:29:29 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format="flowed"; charset="utf-8"
In-Reply-To: <>
Message-Id: <em21aad122-20a0-4d83-8a2b-a9e5d96e8dbe@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <>
User-Agent: eM_Client/5.0.17944.0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-1.851, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.234, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UZUqz-0002BG-L0 f356e6440b35bbda4606c97f272464a4
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <>
X-Mailing-List: <> archive/latest/17849
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Yoav

not everyone here is a member of our choir :)



------ Original Message ------
From: "Yoav Nir" <>
To: "Adrien W. de Croy" <>
Cc: "Werner Baumann" <>; 
"<>" <>
Sent: 6/05/2013 11:00:45 p.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>On May 6, 2013, at 1:37 PM, "Adrien W. de Croy" <>
>  wrote:
>>  Hi
>>  ------ Original Message ------
>>  From: "Yoav Nir" <>
>>  To: "Werner Baumann" <>
>>  Cc: "<>" <>
>>  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 
>>><> wrote:
>>>>  An explicit trusted proxy does not meet this definition of 
>>>>  because of condition 1. Whether information is delivered to a third
>>>>  party at all depends on the administration of that proxy. End users 
>>>>  have to decide whether to trust it or not (which is much more easy 
>>>>  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 
>>  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 
>>  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.