Re: Comments on Explicit/Trusted Proxy

[Roberto Peon <[e-mail]>]

and by hand-wavy I mean intentionally vague.
-=R


On Fri, May 3, 2013 at 9:15 AM, Roberto Peon <[e-mail]> wrote:

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