Re: Trusted proxy UI strawman

From your MITM cache tainting issue: https://code.google.com/p/chromium/issues/detail?id=81623#c15

"Trying to do better than that seems very difficult. We could split the cache, but then we don't know which cache to use until we make an SSL connection and see whether it's a MITM connection. That completely twists the HTTP stack around and I don't think we would do that for a feature this minor."

The more important question is whether or not tainted content is being served, not whether or not the user has been informed. I'm surprised this is considered a minor feature. Since chrome can detect the difference between MITM'd content and non-MITM'd content, I would expect it to keep those in different cache partitions. In any case, this seems like one of many implementation details that will need to be sorted out with the addition of trusted proxy support that no doubt should have been sorted out with the implicit support for MITMs long ago.

Thanks,

Peter



On Jun 16, 2014, at 3:47 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> On Jun 16, 2014 2:19 PM, <bizzbyster@gmail.com> wrote:
> >
> > Hi Will,
> >
> > Thanks for your inputs. Enjoy the trekking!
> >
> > A few follow up comments inline -- no rush to reply.
> >
> > Peter
> >
> > On Jun 16, 2014, at 7:33 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:
> >
> >> Apologies for the slow reply. I'm still traveling around Iceland and you can expect high latency on responses from me (I'll be hiking some mountain summits / glaciers these next few days).
> >>
> >> On Sun, Jun 15, 2014 at 12:34 PM, <bizzbyster@gmail.com> wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> Thanks for taking a look.
> >>>
> >>>
> >>> "is the decision to accept the proxy a blocking one? That is, is the user able to use the Web prior to making this decision?"
> >>>
> >>> Sorry if the presentation was not clear but the proxy is deployed inline so the user has no choice on whether or not the proxy will be able to process his/her bits. The question is whether or not the user wants to give the proxy consent to decrypt the TLS-encrypted bits. This is done by first importing the trusted proxy certificate, which is an identical process to importing a root certificate today. In fact I'd argue the proposed trusted proxy import dialog is more clear to the user that he/she is in fact allowing the proxy to decrypt and alter traffic than the root certificate import dialog is today.
> >>
> >>
> >> It's definitely offering more information, although the information may mislead the user.
> >
> > I find the current CA import dialog very misleading. Also it puts the burden of informing the user about what they are agreeing to on what is contained in the certificate. I'd like to be less misleading if at all possible so if you can think of improvements on what I have here let me know.
> >
> >>  
> >>>
> >>>
> >>> "https://bankofamerica.com/ might be a bad choice of example, though I'm guessing that you chose a banking site intentionally. Personally, I find the idea that there is a MitM on a connection to my bank to be almost as disturbing as having my visit to a doctor monitored."
> >>>
> >>> Yes. We intentionally showed a banking site because that might be one where many users decide to opt out of trusting the proxy, which is what is being demonstrated in that screenshot. Again, it's important to note that if the user had imported a root certificate he/she would see no notification when browsing to an https banking site and would not be prompted to opt out.
> >>
> >>
> >> As shown in the presentation, the opt out happens after the fact. So the proxy already was able to decrypt the first navigation, which is problematic from a privacy/security perspective. Also, there needs to be clarity around whether or not this applies on an origin granularity. Also, there are security issues with regards to caching subresources (especially active content like script) which may have been hosted on 3rd party origins. The taint analysis here is very complicated and perhaps even intractable.
> >
> > I agree that this is a big problem. We have alternate treatments where we ask the user prior to going to visiting a page but these just seemed very clunky and would be even more annoying to the user than the info bar on every single new HTTPS web site. Also, since the user decided to import the trusted proxy certificate in the first place he/she is agreeing at some level to trust the proxy. But I agree that opt-out after the fact is a big weakness in the proposed model.
> >
> > I don't follow what you are saying about security issues around caching sub resources for active content? How is it different from when trusted proxy is not active? 
> 
> Let's say I visit https://foo.com which uses a jQuery URL (perhaps hosted by a CDN like Google's). A MITM proxy can cause a non-canonical version of jQuery to be cached. Now I visit https://bar.com which also references the same jQuery URL, but I want to opt out of https://bar.com getting MITM'd. In the fallback, does it load the tainted jQuery resource from cache? Even if not, it's important to note that once tainted active web content is loaded once, it can spread virally to other web storage beyond the cache, like localStorage, IndexedDB, etc and acquire web permissions (Geolocation, webcam, etc).
> 
> For more details, please refer to https://code.google.com/p/chromium/issues/detail?id=81623#c15 and other comments on that bug thread.
> 
> >
> >>
> >> Also, showing an infobar on every single new HTTPS website navigated to sounds like it may lead to UI fatigue.
> >
> > Yes agreed. But is it worse than what Chrome supports today in allowing MITM without any notification all? It'd be great to come up with ways to improve this experience.
> 
> It's probably worse. It's risky to take the approach of "better to show something than nothing at all" if the something just trains users to ignore your signals. Maybe later we will come up with a better heuristic, but we've already trained people to ignore our UI warnings. A better way would perhaps be something like suggested in https://code.google.com/p/chromium/issues/detail?id=81623. But unfortunately, due to the technical issue I referenced earlier with tainting web resources that were MITM'd, we can't provide a meaningful UI indicator.
> 
> >
> >>  
> >>>
> >>>
> >>> The whole idea of this proposal is to make it no different than today's MITM except for the fact that the user is made aware of the decryption and is able to opt out on a per site or on a global basis by either uninstalling the trusted proxy certificate or going to the browser settings and turning it off.
> >>>
> >>> Thanks,
> >>>
> >>> Peter
> >>>
> >>>
> >>> On Jun 15, 2014, at 2:25 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> >>>
> >>>>
> >>>> On 14 June 2014 17:02, <bizzbyster@gmail.com> wrote:
> >>>> > I agree. Here's a straw man to get the discussion going:
> >>>> > http://caffeinatetheweb.com/presentations/trusted_proxy.html.
> >>>>
> >>>> I have a lot of questions, but I'll start with this one: is the decision to accept the proxy a blocking one? That is, is the user able to use the Web prior to making this decision? That makes a very big difference.
> >>>>
> >>>> I also have a few things that you might like to think about:
> >>>>
> >>>> https://bankofamerica.com/ might be a bad choice of example, though I'm guessing that you chose a banking site intentionally. Personally, I find the idea that there is a MitM on a connection to my bank to be almost as disturbing as having my visit to a doctor monitored.
> >>>>
> >>>> This sort of work might not be in scope here. I understand that we need to have this discussion somewhere, but the IETF (and even the W3C) have so far avoided dealing with these sorts of issues. That's probably not the right answer, but I keep hearing that this is outside their area of expertise.
> >>>
> >>>
> >>
> >