- From: Adrien W. de Croy <adrien@qbik.com>
- Date: Fri, 03 May 2013 11:16:28 +0000
- To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "HTTP Working Group" <ietf-http-wg@w3.org>
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/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 >>><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 11:17:03 UTC