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

Re: Comments on Explicit/Trusted Proxy

From: Adrien W. de Croy <adrien@qbik.com>
Date: Fri, 03 May 2013 20:27:06 +0000
To: "Roberto Peon" <grmocg@gmail.com>
Cc: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em09a61c11-4e1a-4202-800a-d847be074471@bombed>

my next question, is how can the server tell the difference between a 
proxy and a client?


------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 4/05/2013 4:23:10 a.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>
>A proxy can represent the interests of a 3rd party which has nothing to 
>do with the client or server. The motivations of this 3rd party may not 
>be known, and are often enough antithetical to the wishes of the client 
>or server.
>
>The motivation of the client is more likely known-- they simply want 
>the content the server is providing, without allowing it to be modified 
>in ways which make for a poor experience (not just that page load, but 
>overall, including things like not having their bank account 
>mysteriously go to zero).
>
>-=R
>
>
>On Fri, May 3, 2013 at 4:16 AM, Adrien W. de Croy <adrien@qbik.com> 
>wrote:
>>
>>As far as a server is concerned, why would a client be any more 
>>trustable than a proxy?
>>
>>
>>
>>Adrien
>>
>>------ Original Message ------
>>From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>>To: "HTTP Working Group" <ietf-http-wg@w3.org>
>>Sent: 3/05/2013 8:16:33 p.m.
>>Subject: Re: Comments on Explicit/Trusted Proxy
>>>
>>>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/orhttp://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 20:27:38 UTC

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