Re: Comments on Explicit/Trusted Proxy

Roberto Peon <grmocg@gmail.com> Fri, 03 May 2013 00:15 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 A40A421F8FC6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 2 May 2013 17:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level:
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=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 2K7Zqx-VesJY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 2 May 2013 17:15:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2A07621F8FC4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 2 May 2013 17:15:21 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UY3dS-000450-DJ for ietf-http-wg-dist@listhub.w3.org; Fri, 03 May 2013 00:14:02 +0000
Resent-Date: Fri, 03 May 2013 00:14:02 +0000
Resent-Message-Id: <E1UY3dS-000450-DJ@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UY3dF-000449-P4 for ietf-http-wg@listhub.w3.org; Fri, 03 May 2013 00:13:49 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UY3dD-0003FK-Mw for ietf-http-wg@w3.org; Fri, 03 May 2013 00:13:49 +0000
Received: by mail-ob0-f178.google.com with SMTP id 16so998909obc.37 for <ietf-http-wg@w3.org>; Thu, 02 May 2013 17:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FBdrQC9VNNAec+4ifasrcu237teFISzXeHw5OHTHA2k=; b=vNUtF4KxmOxlLcW31mxvb03BsO73xfj1JCLMtjHM/P91EvV3tUVP1ODTaU23g2olOX KOU8DA6Ai9XGorS7kd4LAbosRcLAEnoYlEzEaxs0gx1d3LNsfivktnCfwXzBJBBJSWEe IhgbaGuP295eWXlO5HkN3SThbx5qVY3Qcb+rmQuGUC3z1ArXXPZNpInxZU7XgPUFw3P4 CT2m7JWD+7KQdcxnMgqFYvZPhQ+Lxtr0UxpR9rVTotIA7/t3aagpI24Bm5n1qeknVmjs gqKXXdJbQ3LlJdqJkEKJF+dnfglEeezVDlgO3HZI8xXg1PAJroaqquZXvsnTtGoCM8H9 ntJA==
MIME-Version: 1.0
X-Received: by 10.60.141.35 with SMTP id rl3mr2342170oeb.121.1367540001108; Thu, 02 May 2013 17:13:21 -0700 (PDT)
Received: by 10.76.130.139 with HTTP; Thu, 2 May 2013 17:13:21 -0700 (PDT)
In-Reply-To: <896F1026-30C6-4397-B265-67285BFA9DDA@gmail.com>
References: <14A09626-8397-4656-A042-FEFDDD017C9F@mnot.net> <CANmPAYH60+wmeYQAikUd4ps3HdPQSm80TeZbMW37LioBYVj-7A@mail.gmail.com> <CAA4WUYjOPgCse6giEmy3f_MzRTC3K25oAWeAavHnzywc5pL91w@mail.gmail.com> <CANmPAYGr8QDhmLR50UzWYWK_fNYzGbF_P9EN0dOadmL-wQy61g@mail.gmail.com> <CAA4WUYjDoRFwPJNWzRqQHdBbV+DjF0mv8OO4RWTBSmh6=Dcnxw@mail.gmail.com> <CANmPAYEirEfpM6kEuxaM3OF7hsjWu8_Lr0aWfQ+btkEGOH3Vsw@mail.gmail.com> <CAA4WUYjGaZRVm3NtmT5qO3j7QKNZZiX7zBEV-pDhK0VGGSxuUg@mail.gmail.com> <896F1026-30C6-4397-B265-67285BFA9DDA@gmail.com>
Date: Thu, 2 May 2013 17:13:21 -0700
Message-ID: <CAP+FsNeyHdUrQxgU-Y+U6jXzKGruHeBc9KEuUQMYKOYAh=hVog@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=047d7b339dbbfb7c8204dbc5378e
Received-SPF: pass client-ip=209.85.214.178; envelope-from=grmocg@gmail.com; helo=mail-ob0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.686, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UY3dD-0003FK-Mw 5515b80c7266f09fd9f0b2166253b50b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <http://www.w3.org/mid/CAP+FsNeyHdUrQxgU-Y+U6jXzKGruHeBc9KEuUQMYKOYAh=hVog@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17791
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>

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