- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Fri, 03 May 2013 09:16:33 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
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 08:16:57 UTC