Re: Trusted proxy UI strawman

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.


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

Also, showing an infobar on every single new HTTPS website navigated to
sounds like it may lead to UI fatigue.


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