Re: Trusted proxy UI strawman

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