- From: Peter Lepeska <bizzbyster@gmail.com>
- Date: Thu, 2 May 2013 10:53:33 -0400
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: Yoav Nir <ynir@checkpoint.com>, HTTP Working Group <ietf-http-wg@w3.org>
It's no different than today. If you have a root CA installed on the end users machine, you can MITM the bank. Under this scheme, there will be some proxies that will elect to not MITM traffic from content providers that explicitly opt-out. In general, adding support for an SSL proxy should not decrease the level of security from MITM attacks that we have today. It just allows well-behaving ones to A) not have to forge certificates, B) remove the problem of transitive trust, and C) make content servers aware and give them the ability to opt-out. Peter On May 2, 2013, at 10:47 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > > On 05/02/2013 03:34 PM, Peter Lepeska wrote: >> Stephen, >> >> I agree with you about bank sites but HTTPS is increasingly used for sites that transfer much less sensitive information. Over very high latency networks like satellite (full disclosure: my job is to optimize Viasat's Exede network) the adoption of HTTPS is hurting page load performance. The primary reason for this is that our HTTP prefetching that is built into the network cannot be applied to encrypted traffic. >> >> For example, www.usps.com recently switched from plain HTTP to HTTPS. It's page load time went from ~5 seconds to ~30 seconds over satellite. If the protocol was changed to support the advertisement of an accelerating proxy to the content server, for instance with a flag in the ClientHello, my guess is that many content owners like www.usps.com would agree to allow the proxy to decrypt/re-encrypt for the purposes of speeding up access to that site for their users. On the other hand, a bank would likely refuse, which again the protocol could support via a flag in the ServerHello that is processed by the proxy telling it that the information is too sensitive for optimization. > > I don't know how you can do that and prevent someone from MTIM'ing > the bank. That's the problem with all this so-called "trusted" proxy > stuff. > > S. > >> In general, SPDY adds the HTTPS requirement and Prefetching to HTTP. But the HTTPS requirement limits the prefetching benefit b/c proxies that can learn which objects a given site will need are increasingly unable to see the traffic. >> >>> Again, that's for the TLS wg. As Yoav notes, you can be the >>> N-th set of people who want to standardise a MITM. Expect >>> resistance;-) >> >> >> Yes. I see that TLS wg is not receptive to this. My hope is to prototype this functionality and then submit a draft update of the mcgrew approach with tweaks and working code. I'll submit it to the TLS wg unless there is interest here. >> >> Thanks, >> >> Peter >> >> >> On May 2, 2013, at 5:09 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> >>> On 05/02/2013 02:55 AM, Peter Lepeska wrote: >>>> I like the mcgrew proposal best as well. I like the way that it removes the "transitive trust" problem without having a tunnel within a tunnel and the passing of encryption keys over the air, which is the approach used in Roberto's draft as I understand it. >>> >>> Again, that's for the TLS wg. As Yoav notes, you can be the >>> N-th set of people who want to standardise a MITM. Expect >>> resistance;-) >>> >>>> SPDY is increasing the adoption of SSL, which is rendering traditional caches less and less useful. At minimum it would be great to have agreement on what the protocol to support a trusted proxy would look like. >>> >>> Personally, I don't believe I've seen a coherent description >>> of what this kind of MITM is supposed to be, except for those >>> that call it a MITM. My guess (no more than that) is that you'd >>> probably need some new semantics for HTTP to actually support >>> the kind of thing people say they want. >>> >>>> Even better would be if Chrome or another browser led the way and implemented it. >>> >>> I disagree fwiw. I think its bad enough that there are MITM >>> proxy products being deployed and am happy that browsers >>> seem mostly to prefer to actually want to talk to the real >>> server that has the relevant private key. I really do prefer >>> that when I want to do banking that no corporate MITM gets access >>> to my bank account. (Mind you, I also have the protection of >>> an almost always near-zero bank account;-) If I needed to collude >>> with someone via one of these boxes, I and anyone else am >>> also quite capable of bypassing any outbound content analysis >>> that such proxies might attempt, and I have to have sufficient >>> security on the box with the browser to handle inbound malware >>> in any case (e.g. that arrives via mail) so the security argument >>> for these MITMs is to a large degree (though not quite 100%) >>> bogus IMO. Just because some people get sold a pup doesn't >>> mean we should turn TLS into a dog:-) >>> >>> S. >>> >>>> >>>> Peter >>>> >>>> On Apr 27, 2013, at 4:09 PM, Yoav Nir <ynir@checkpoint.com> wrote: >>>> >>>>> Here's one (I'm a co-author) >>>>> >>>>> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server >>>>> >>>>> One reason this was rejected is that MitM proxies are used for corporate firewalls and national firewalls, so the use case seems to be "Alice wants to post to Twitter trashing president Assad. Mallory who works for the secret police would like to catch her, so he installs a proxy." The feedback said that if whoever wants the inspection (call them Mallory for now) can configure trust on Alice's client, they might as well install spyware instead. Another idea that was floated was to have the client send the keys to the trusted proxy. That way, the client could send just the encryption key (but not the hash key) so the proxy would be able to decrypt, but not forge. I didn't like that, but I did try to write a draft describing it: >>>>> >>>>> http://tools.ietf.org/html/draft-nir-tls-keyshare >>>>> >>>>> I still think this solution is unwieldy. >>>>> >>>>> Anyway, the TLS WG can re-consider things. NPN was suggested several times. If there is a use case that is not "Mallory wants to see what Alice is telling Bob", a request from this WG would go a long way, regardless of which mechanism is preferred for enabling a trusted proxy. >>>>> >>>>> Yoav >>>>> >>>>> On Apr 26, 2013, at 3:45 PM, Peter Lepeska <bizzbyster@gmail.com> wrote: >>>>> >>>>>> Hi Stephen. >>>>>> >>>>>> I was responding to Roberto's draft, which was submitted to this list. But my suggestion crosses over into TLS changes so I'll read up on the 5 previous discussions and post to the TLS group if appropriate. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Peter >>>>>> >>>>>> >>>>>> On Apr 26, 2013, at 6:43 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: >>>>>> >>>>>>> >>>>>>> Hi Peter, >>>>>>> >>>>>>> If you want to modify TLS, then that's work that would >>>>>>> need to be done in the TLS working group and not here. >>>>>>> Note that this'd be about the 5th time someone has asked >>>>>>> if we want to standardise how to do a MITM attack on TLS, >>>>>>> which is a protocol designed specifically to deter MITM >>>>>>> attacks, and the answer has always been an emphatic no. >>>>>>> I cannot see that changing. As a current security AD I >>>>>>> know I'd have a huge problem with standardising that >>>>>>> attack as I believe would my co-AD who's responsible >>>>>>> for the TLS WG. >>>>>>> >>>>>>> If you want to propose changes to the semantics of HTTP, >>>>>>> and supporting MITM proxies would be one such IMO, then >>>>>>> I guess take that up with Mark. Or not, since I don't >>>>>>> believe this WG is chartered to develop new semantics >>>>>>> for HTTP at present. >>>>>>> >>>>>>> Regard, >>>>>>> Stephen. >>>>>>> >>>>>>> On 04/25/2013 09:38 PM, Peter Lepeska 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/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Email secured by Check Point >>>>> >>>> >>>> >>>> >> >> >> >>
Received on Thursday, 2 May 2013 14:54:01 UTC