Re: Comments on Explicit/Trusted Proxy

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 03 May 2013 08:18 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 C8E8521F9485 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 01:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.505
X-Spam-Level:
X-Spam-Status: No, score=-7.505 tagged_above=-999 required=5 tests=[AWL=3.094, BAYES_00=-2.599, 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 RPe7foTqENrF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 01:18:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCC521F9357 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 May 2013 01:18:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYBAw-0003Fk-J3 for ietf-http-wg-dist@listhub.w3.org; Fri, 03 May 2013 08:17:06 +0000
Resent-Date: Fri, 03 May 2013 08:17:06 +0000
Resent-Message-Id: <E1UYBAw-0003Fk-J3@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1UYBAn-0003Bk-0Y for ietf-http-wg@listhub.w3.org; Fri, 03 May 2013 08:16:57 +0000
Received: from mercury.scss.tcd.ie ([134.226.56.6]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1UYBAk-0000fO-Ub for ietf-http-wg@w3.org; Fri, 03 May 2013 08:16:56 +0000
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9CCCEBE8A for <ietf-http-wg@w3.org>; Fri, 3 May 2013 09:16:33 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrfr6IpWIt21 for <ietf-http-wg@w3.org>; Fri, 3 May 2013 09:16:33 +0100 (IST)
Received: from [IPv6:2001:770:10:203:2080:f244:5ffe:95de] (unknown [IPv6:2001:770:10:203:2080:f244:5ffe:95de]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78117BE6E for <ietf-http-wg@w3.org>; Fri, 3 May 2013 09:16:33 +0100 (IST)
Message-ID: <51837261.9050102@cs.tcd.ie>
Date: Fri, 03 May 2013 09:16:33 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: HTTP Working Group <ietf-http-wg@w3.org>
References: <CAP+FsNeyHdUrQxgU-Y+U6jXzKGruHeBc9KEuUQMYKOYAh=hVog@mail.gmail.com> <em6017746b-99eb-4274-a713-2673cb66e45d@bombed> <CAP+FsNfP3gfrKY0kRKu9HGjdAkMv3qReSCAAfNauYQiPrs-mCw@mail.gmail.com>
In-Reply-To: <CAP+FsNfP3gfrKY0kRKu9HGjdAkMv3qReSCAAfNauYQiPrs-mCw@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: none client-ip=134.226.56.6; envelope-from=stephen.farrell@cs.tcd.ie; helo=mercury.scss.tcd.ie
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-2.066, RP_MATCHES_RCVD=-2.581
X-W3C-Scan-Sig: maggie.w3.org 1UYBAk-0000fO-Ub d67d4af14b0e5cab73b965b5fc975bee
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <http://www.w3.org/mid/51837261.9050102@cs.tcd.ie>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17794
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>

The contrast between this arm-waving nonsense and the precision
with which this wg are tackling HTTP/2.0 performance is frankly
astounding.

Every web site in the world (and all the non-HTTP uses of TLS)
are supposed to be able to authenticate every proxy in the world
and know when its ok for a particular set of proxies to MITM an
TLS session? That's just BS.

Note, I'm not specifically directing this at Roberto - I mean
the entire discussion rests on BS notions like the above.

S.

On 05/03/2013 01:53 AM, Roberto Peon wrote:
> The scheme allows for injection of bytes, but not within any of the secure
> tunnels. Instead, the proxy's bytes are clearly demarqued as different.
> 
> The idea here is that the client or server should always know when the
> proxy has changed bytes, and it shouldn't, though it may inject
> bytes/requests/whatever in either direction.
> 
> 
> Sure, a client cert is one way of authenticating to the server. I didn't go
> into that much detail, but rather pointed out that the scheme proposed in
> that doc, that servers may decide they don't want to service queries from
> (some) proxies, and direct the client to either try directly, or allow the
> request to fail.
> 
> -=R
> 
> On Thu, May 2, 2013 at 5:48 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
> 
>>
>> proxies need to be able to modify the bytes or at least inject messages
>> back to the client.
>>
>> e.g.
>>
>> * request denied by policy (e.g. you can't POST to that site due to DLP
>> rules)
>> * serving from cache
>> * ad stripping
>> * malware blocking
>> * etc etc etc
>>
>> let alone stripping hop-by-hop headers etc
>>
>> So I don't think anyone will bother with a scheme that doesn't allow for
>> that.  If the only option of the intermediary is to delay or drop the
>> connection, the client is going to be in the dark as to why.  Already the
>> user experience in this area is poor.
>>
>> As for intercepting proxies.  Whilst I agree they are a PITN, they are
>> strongly favoured by customers for several obvious reasons.
>>
>> Until we can get a wide-spread mechanism deployed to securely FORCE
>> clients to use a proxy, we're going to see interception.
>>
>> As for MITM.  Whilst we continue to think of it as an attack, we will
>> continue to see resistance.  It's clear some people see it only negatively,
>> where others see this as an opportunity to improve things compared to
>> current MITMs.
>>
>> Personally I would rather know what is going on, than be in the dark and
>> be forced to swallow whatever I receive simply because I was forced (by
>> company policy) to install a root cert for the spoofed certs.  Sites using
>> EV certs will show me what is going on if I know a site uses EV certs,
>> since the EV breaks on spoofed certs.  Or I need to check the cert path on
>> any site to see if I can find the forced cert at the root.  But that's me,
>> not everyday punters.
>>
>> As for the server trusting the proxy.  Why is that any different to the
>> server trusting the client.  Use a client cert.  Can always fall back to a
>> tunnel if the server indicates it needs a client cert.  Currently there's
>> no way around this issue in today's MITM systems except for installing the
>> client cert on the proxy.
>>
>> Adrien
>>
>>
>> ------ Original Message ------
>> From: "Roberto Peon" <grmocg@gmail.com>
>> To: "Peter Lepeska" <bizzbyster@gmail.com>
>> Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
>> Sent: 3/05/2013 12:13:21 p.m.
>> Subject: Re: Comments on Explicit/Trusted Proxy
>>
>>  responses inline.
>>
>>
>>  On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <bizzbyster@gmail.com>
>>  wrote:
>>
>>> Some comments on Roberto's doc:
>>>
>>>   In the case where the user-agent has been configured with Chris as a
>>>    trusted-proxy, either Anne's connect-stream MUST use either a null-
>>>    cipher, or Anne MUST provide the decryption key material to Chris
>>>    immediately after tunnel establishment, and before any data traverses
>>>    the tunnel.
>>>
>>>
>>> This seems like a showstopper to me. Even if we can get past the problems
>>> associated with a trusted proxy in general, I can't see getting acceptance
>>> of any approach that involves sending a session key from one machine to
>>> another. But why not just use two full SSL sessions like the typical MITM
>>> proxy (http://crypto.stanford.edu/ssl-mitm/or http://mitmproxy.org/)
>>> approach? But instead of forging certificates like they do, just give the
>>> trusted proxy its own certificate and then display both the trusted proxy
>>> certificate and the content server certificate in the browser when the user
>>> wants info about the two point-to-point SSL sessions.
>>>
>>>
>> Using two connections may require two separate connections at the eventual
>> endpoint, and it contributes to bufferbloat.
>> Also, the proxy may wish to influence the private channel (e.g. don't talk
>> to site X). With connection sharing, this is difficult/impossible otherwise
>> (that other connection may not only go to example.com).
>>
>>
>>>  "For the purpose of this document, it is assumed that the user locates
>>>
>>>    a piece of paper upon a wall and reads it, typing these proxy
>>>    settings into a configuration field for their user-agent.  This is
>>>    obviously not the only possible configuration mechanism, but it may,
>>>    sadly, be the most secure.  It is assumed that alternate distribution
>>>    techniques may be discussed.
>>>
>>> "
>>>
>>> While explicit proxy configuration may be the most secure, it is very
>>> difficult to manage for mobile devices especially, as others have mentioned
>>> on this list. Transparent interception is the more widely adopted approach
>>> -- not because of security but because of stability and manageability.
>>>
>>>
>> There is no secure automatic proxy configuration unless a completely
>> separate trust chain is somehow created and is reliable (or at least moreso
>> than what we have with TLS today).
>> Transparent proxying causes problems in upgrading the protocol as nobody
>> knows where the problem lies. If this wasn't such a painful point, we'd
>> have been using SPDY over port 80...
>> I'm fundamentally opposed to transparent proxying because it makes
>> protocol evolution next to impossible when you can't figure out who is
>> messing up...
>>
>>
>>
>>>  What about "transparent" proxies that advertise themselves? Is it
>>> possible to use NPN (
>>> https://technotes.googlecode.com/git/nextprotoneg.html) to advertise the
>>> presence of an intercepting proxy for 443 traffic? Then the user can be
>>> notified that a proxy wants to be trusted for X reasons and the user would
>>> then make the opt in or opt out decision. Then, similar to SPDY, the
>>> presence of the trusted proxy in the end-to-end path could be signaled to
>>> the end user via icons in the browser.
>>>
>>
>>
>>
>>
>>>
>>> MITM is used today with no user knowledge. At least in this approach, a
>>> user has the ability to opt in or out and to also be aware of the presence
>>> of the intermediate proxy.
>>>
>>
>> That is the idea.
>> Additionally, and this is important, the server gets to decide if the MITM
>> is acceptable, and, in the proposed scheme the MITM doesn't get to modify
>> bytes. It merely gets to advise the recipient of how to deal with them,
>> delay them, or disconnect.
>>
>> -=R
>>
>>
>> On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>>
>>> Some comments on Roberto's doc:
>>>
>>>   In the case where the user-agent has been configured with Chris as a
>>>    trusted-proxy, either Anne's connect-stream MUST use either a null-
>>>    cipher, or Anne MUST provide the decryption key material to Chris
>>>    immediately after tunnel establishment, and before any data traverses
>>>    the tunnel.
>>>
>>>
>>> This seems like a showstopper to me. Even if we can get past the problems
>>> associated with a trusted proxy in general, I can't see getting acceptance
>>> of any approach that involves sending a session key from one machine to
>>> another. But why not just use two full SSL sessions like the typical MITM
>>> proxy (http://crypto.stanford.edu/ssl-mitm/ or http://mitmproxy.org)
>>> approach? But instead of forging certificates like they do, just give the
>>> trusted proxy its own certificate and then display both the trusted proxy
>>> certificate and the content server certificate in the browser when the user
>>> wants info about the two point-to-point SSL sessions.
>>>
>>> "For the purpose of this document, it is assumed that the user locates
>>>
>>>    a piece of paper upon a wall and reads it, typing these proxy
>>>    settings into a configuration field for their user-agent.  This is
>>>    obviously not the only possible configuration mechanism, but it may,
>>>    sadly, be the most secure.  It is assumed that alternate distribution
>>>    techniques may be discussed.
>>>
>>> "
>>>
>>> While explicit proxy configuration may be the most secure, it is very
>>> difficult to manage for mobile devices especially, as others have mentioned
>>> on this list. Transparent interception is the more widely adopted approach
>>> -- not because of security but because of stability and manageability.
>>>
>>> What about "transparent" proxies that advertise themselves? Is it
>>> possible to use NPN (
>>> https://technotes.googlecode.com/git/nextprotoneg.html) to advertise the
>>> presence of an intercepting proxy for 443 traffic? Then the user can be
>>> notified that a proxy wants to be trusted for X reasons and the user would
>>> then make the opt in or opt out decision. Then, similar to SPDY, the
>>> presence of the trusted proxy in the end-to-end path could be signaled to
>>> the end user via icons in the browser.
>>>
>>> MITM is used today with no user knowledge. At least in this approach, a
>>> user has the ability to opt in or out and to also be aware of the presence
>>> of the intermediate proxy.
>>>
>>> Thoughts?
>>>
>>> Peter
>>>
>>>
>>>  On Apr 24, 2013, at 12:49 PM, William Chan (陈智昌) <willchan@chromium.org>
>>> wrote:
>>>
>>>  Yep, but no, it hasn't gone anywhere.
>>>
>>>
>>> On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>>>
>>>> Hi William,
>>>>
>>>> Is this draft by Roberto Peon the one you were referring to?
>>>>
>>>> http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00
>>>>
>>>> Has this gone anywhere?
>>>>
>>>> I'm looking to design and build a "trusted proxy" that aligns with the
>>>> browser development roadmap/vision in order to provide web acceleration
>>>> functionality and so would like to get involved in this process if still
>>>> active.
>>>>
>>>> Thanks,
>>>>
>>>> Peter
>>>>
>>>>
>>>> On Mon, Apr 30, 2012 at 5:57 PM, William Chan (陈智昌) <
>>>> willchan@chromium.org> wrote:
>>>>
>>>>> On the contrary, I think it's great to have multiple proposals. If you
>>>>> have your own vision for how this should work, please send it out! :) My
>>>>> statement was simply an FYI, not a "back off, we've got this!"
>>>>>
>>>>> On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>>>>>
>>>>>> Perfect then I'll sit tight.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) <
>>>>>> willchan@chromium.org> wrote:
>>>>>>
>>>>>>> FYI, we (google spdy team) have been discussing a "trusted proxy"
>>>>>>> internally and I think Roberto's got a draft in the works.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 30, 2012 at 2:22 PM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>>>>>>>
>>>>>>>> Hi Mark,
>>>>>>>>
>>>>>>>> Earlier this group discussed the idea of a "trusted proxy". Does
>>>>>>>> that fall under the HTTP/2.0 category?
>>>>>>>>
>>>>>>>> I may have some cycles for this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham <mnot@mnot.net>wrote:
>>>>>>>>
>>>>>>>>> Just a reminder that we're still accepting proposals for:
>>>>>>>>>
>>>>>>>>> 1. HTTP/2.0
>>>>>>>>> 2. New HTTP authentication schemes
>>>>>>>>>
>>>>>>>>> As per our charter <http://datatracker.ietf.org/wg/httpbis/charter/
>>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> So far, we've received the following proposals applicable to
>>>>>>>>> HTTP/2.0:
>>>>>>>>>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
>>>>>>>>>
>>>>>>>>> But none yet for authentication schemes:
>>>>>>>>>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As communicated in Paris, the deadline for proposals is 15 June,
>>>>>>>>> 2012. It's fine if your proposal isn't complete, but we do need to have a
>>>>>>>>>  good sense of it by then, for discussion.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mark Nottingham   http://www.mnot.net/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>