Re: Comments on Explicit/Trusted Proxy
"Adrien W. de Croy" <adrien@qbik.com> Mon, 06 May 2013 23:32 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDF21F9283 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 May 2013 16:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C092iQEl44Qd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 May 2013 16:31:58 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id EB60C21F92CB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 May 2013 16:31:54 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UZUrF-0006Ee-FN for ietf-http-wg-dist@listhub.w3.org; Mon, 06 May 2013 23:30:13 +0000
Resent-Date: Mon, 06 May 2013 23:30:13 +0000
Resent-Message-Id: <E1UZUrF-0006Ee-FN@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UZUr1-00034P-9b for ietf-http-wg@listhub.w3.org; Mon, 06 May 2013 23:29:59 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UZUqz-0002BG-L0 for ietf-http-wg@w3.org; Mon, 06 May 2013 23:29:59 +0000
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4550)) with SMTP id <0019696664@smtp.qbik.com>; Tue, 07 May 2013 11:29:29 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Werner Baumann <werner.baumann@onlinehome.de>, "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
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: <9EA8F4F3-7886-4D28-93B7-A22CE6961BA5@checkpoint.com>
Message-Id: <em21aad122-20a0-4d83-8a2b-a9e5d96e8dbe@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.17944.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
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: lisa.w3.org 1UZUqz-0002BG-L0 f356e6440b35bbda4606c97f272464a4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <http://www.w3.org/mid/em21aad122-20a0-4d83-8a2b-a9e5d96e8dbe@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17849
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi Yoav not everyone here is a member of our choir :) Regards Adrien ------ Original Message ------ From: "Yoav Nir" <ynir@checkpoint.com> To: "Adrien W. de Croy" <adrien@qbik.com> Cc: "Werner Baumann" <werner.baumann@onlinehome.de>; "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org> Sent: 6/05/2013 11:00:45 p.m. Subject: 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 >
- Reminder: Call for Proposals - HTTP/2.0 and HTTP … Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Willy Tarreau
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Willy Tarreau
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Re: Reminder: Call for Proposals - HTTP Authentic… Mark Nottingham
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP Authentic… Mark Nottingham
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- RE: Reminder: Call for Proposals - HTTP Authentic… Markus.Isomaki
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Fabian Keil
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Albert Lunde
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Benjamin Carlyle
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Werner Baumann
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy