- 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