Re: Trusted proxy UI strawman

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? 

> 
> 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.

>  
> 
> 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.
>> 
> 
>