W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Comments on Explicit/Trusted Proxy

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 03 May 2013 09:16:33 +0100
Message-ID: <51837261.9050102@cs.tcd.ie>
To: HTTP Working Group <ietf-http-wg@w3.org>

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/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
Received on Friday, 3 May 2013 08:16:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC