Re: Comments on Explicit/Trusted Proxy

["Adrien W. de Croy" <[e-mail]>]

As far as a server is concerned, why would a client be any more 
trustable than a proxy?


Adrien

------ Original Message ------
From: "Stephen Farrell" <[e-mail]>
To: "HTTP Working Group" <[e-mail]>
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 <[e-mail]> 
>>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" <[e-mail]>
>>>  To: "Peter Lepeska" <[e-mail]>
>>>  Cc: "HTTP Working Group" <[e-mail]>
>>>  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 
>>><[e-mail]>
>>>   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 
>>><[e-mail]>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 (陈智昌) 
>>>><[e-mail]>
>>>>  wrote:
>>>>
>>>>   Yep, but no, it hasn't gone anywhere.
>>>>
>>>>
>>>>  On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska 
>>>><[e-mail]>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 (陈智昌) <
>>>>>  [e-mail]> 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 
>>>>>><[e-mail]>wrote:
>>>>>>
>>>>>>>  Perfect then I'll sit tight.
>>>>>>>
>>>>>>>  Thanks,
>>>>>>>
>>>>>>>  Peter
>>>>>>>
>>>>>>>
>>>>>>>  On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) <
>>>>>>>  [e-mail]> 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 
>>>>>>>><[e-mail]>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 
>>>>>>>>><[e-mail]>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/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>