Trusted proxy UI redux

I wonder if the browser guys can weigh in on this. Martin, Patrick, Will, Rob? Others? Do you agree that our choices are as follows?

1) Do nothing. This is today's MITM with user installed CAs.
2) Some type of trusted proxy UI support that gives the user notification and control. Something similar to this: http://caffeinatetheweb.com/presentations/trusted_proxy.html#/.
3) Disable all mechanisms for HTTPS decryption by proxies (for instance, enforce pinned certs)

Do you agree that #3 is not an option b/c browsers will immediately stop working for a large number of corporate users? And that #2 is an improvement over #1 since it does not increase security vulnerability but gives user some visibility and control?

As others have pointed out,  this may not actually be an HTTPbis protocol issue. But I think if we can come to an agreement that something should be done then we can figure out where that work should take place.

Thoughts?

Thanks,

Peter


On Jun 19, 2014, at 11:39 AM, bizzbyster@gmail.com wrote:

> Right.
> 
> Barry is introducing a third option, which is to disable all mechanisms for HTTPS decryption by proxies. 
> 
> So to summarize:
> 
> A) Trusted proxy with notification and user control
> B) Today's MITM with user installed CAs
> C) Disable all mechanisms for HTTPS decryption by proxies.
> 
> A test of the viability of C is the way that pinned certs are handled. If a given browser were to enforce them then that browser would immediately stop working completely within a large number of corporate networks. Which browser manufacturer is going to make this change?
> 
> In my opinion, our choices are between doing nothing and improving on the status quo without introducing any new vulnerabilities.
> 
> Thanks,
> 
> Peter
> 
> 
> On Jun 18, 2014, at 10:46 PM, Adrien de Croy <adrien@qbik.com> wrote:
> 
>> 
>> I think any efforts to block out the possibility for intermediaries to inspect and modify traffic in HTTP would be wasted.
>> 
>> You're unlikely to be able to convince the operators of every corporate network in the world that they no longer need to do this to their users' traffic.
>> 
>> Putting that sort of thing into http/2.0 would simply result in the failure of that protocol to be adopted / allowed in these networks.
>> 
>> Not all https traffic is desirable (e.g. malware downloads, uploading company secrets to file sharing sites etc).  The user is not always the one with all the rights, sometimes network operators must assert their rights and terms of use for their networks.
>> 
>> 
>> 
>> ------ Original Message ------
>> From: "Barry Leiba" <barryleiba@computer.org>
>> To: "Peter Lepeska" <bizzbyster@gmail.com>
>> Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
>> Sent: 19/06/2014 9:02:05 a.m.
>> Subject: Re: Trusted proxy UI strawman
>> 
>>>> 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
>>> 
>> 
>