Re: Comments on Explicit/Trusted Proxy

[Roberto Peon <[e-mail]>]

responses inline


On Fri, May 3, 2013 at 1:16 AM, Stephen Farrell
<[e-mail]>wrote:

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

One puts effort towards defining something precisely when it is believed
that it is useful to do so. At the moment we're arguing about concepts and
seeing if there is/was interest.

Precision for precision's sake seems like it would be a waste of time
better spent adding clarifications, collecting data, etc. for HTTP/2 given
that this would ultimately be decided by a different working group.


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

Why would this be hard? You potentially have a whitelist of proxies that
you do trust, and you tell everyone else to go away. Or you simply tell
everyone to go away for whatever URLs you believe are too sensitive to
allow through a proxy (I'd say that should be my login credentials and
similar data). In the end the policy may have little to do with
authenticating proxies and more about the URLs being served. It IS possible
for a site to decide to authenticate proxies, however, and thus
discriminate if it so chooses (i.e. if the benefit in doing so is high
enough), which is why someone brought it up. Since I didn't really think
authenticating proxies was important, it isn't in the I-D.


The basic idea here was that if I'm a bank or similar, I'm happy to have a
proxy which allows people in places with high RTTs to use a content caching
proxy for non-sensitive data-- better user experience, more happy users.

I'd not be happy, however, allowing this entity to change the bits on the
wire of things flowing to the client, even if I was happy allowing them to
be cached, as this could possibly cause a security breach of their data.
I'd not be happy allowing that proxy to see my client's sensitive financial
data (or I may not be allowed by law to let them see it).

As a content provider I may be perfectly fine with having the javascript
for my page cached, but I really don't want it modified, else instead of
simply allowing DENY/REJECT/DELAY policies, I've instead allowed an easy
vector for the proxy to take control of every session which passes through
it.

The intent was to provide a middle ground whereby both the client and the
server get to decide what powers to grant the proxy.

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

I have a propensity to speak less than I should, which occasionally causes
confusion. Hopefully the above has clarified the intent, but if not, please
continue to ask questions.

There is one part where I was hand-wavy in the I-D, calling out for
discussion to be had, which was around the mechanism by which we configure
the proxies. I still believe that to be the biggest and thorniest issue
(and one which isn't merely technical). If that can't be solved, then any
scheme doing MITM for point-to-point private stuff will fail, and all the
rest of the stuff here and in the draft are for naught.

-=R


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