W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Trusted proxy UI strawman

From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 18 Jun 2014 17:02:05 -0400
Message-ID: <CALaySJJmXHQCKksFNq7dMjBsE1UF1TLDLkYgeRnavwHtfHh6nA@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
> But the situation is much worse today! Look at the dialog on the left:
> http://caffeinatetheweb.com/presentations/trusted_proxy.html#/3

I don't see any sense in which the dialogue on the right is better.
They're both useless, and neither should be presented to my mother.

> At least what I am proposing involves telling the user explicitly that the
> certificate enables the proxy to decrypt and alter traffic. And then
> provides an indication that it is active and a means to disable it. You
> don't see this as an improvement over the current MITM functionality
> supported in all the mainstream browsers?

I don't see it as an improvement because it's nothing that most users
will understand.  To most users, there will be no difference.

The problem isn't that we're not telling users that our proxies can
snoop and modify.  The problem is that we're allowing a situation
where our proxies can snoop and modify.

> Again, because pinning is not enforced if the trust anchor is a user
> installed CA, browser manufacturers are in fact choosing to support MITM
> proxies. But they are doing it without informing the user when it is being
> enabled and without any indication to the user when it's active.  I don't
> understand why anyone would defend the status quo on this.

It's not a question of defending the status quo.  If we're going to
fix this, we need to fix it correctly: we need to tighten up the
protocols and how they're used so that we shut down men in the middle.
And then we have to teach users to use only browsers that do it right
and don't expose them.  We'd do that through major media campaigns
with understandable explanations, not with incomprehensible popup
messages that users won't understand.

Barry
Received on Wednesday, 18 June 2014 21:02:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC