Re: Trusted proxy UI redux

Not speaking for anyone but myself (but somewhat informed by speaking to lots of people):

On 25 Jun 2014, at 12:43 am, bizzbyster@gmail.com wrote:

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

See also:
  https://datatracker.ietf.org/wg/trans/charter/
  http://www.certificate-transparency.org


> Do you agree that #3 is not an option b/c browsers will immediately stop working for a large number of corporate users?

Corporate users are indeed the hard part. It may be that people simply won't access their banks through corporate networks, because they can't, and maybe that's a good outcome -- especially when they're easily able to use a mobile device and get a "clean" connection.

Harder are the sites that users need to legitimately access on an "owned" network (whether it be corporate, school, prison, etc.). 

As things sit now, it may be that we see greater differentiation emerge in the market, where some browsers are easier for corporations to modify / configure in this manner than others. After all, we already see wider deployment of some browsers in corporate settings, whereas other browsers are focusing on individual users and their need for privacy and security.

CT also comes into it; I'm not sure what the current story is around certs that fail CT but match a user-added CA in the trust store, but it seems relevant.

What would be nice is better UX around the trust store, but so far nothing has congealed here or elsewhere (and that sounds very much like an "elsewhere"). One problem is that trust stores are often part of the OS, and as a result both move more slowly and have less-than-ideal integration with browser UX.

Whether or not a standard is required here is a very separate question. It's important to understand that anything that legitimises intercepting traffic is going to encounter a *lot* of friction in the IETF (as well as the W3C, I imagine); while we all know that this happens in some networks (sometimes often), calling it an Internet Standard puts the imprimatur of the organisation on this practice.

That's not to say that we can't have this discussion, or that it won't lead to anything; just that arguments that "look, it's already happening" (which come up once in a while) aren't going to move things forward. My impression is that the browser folks are still figuring out the implications of all of this now, and running their experiments. Forcing them to the table to discuss standards at this stage may not be productive.


> And that #2 is an improvement over #1 since it does not increase security vulnerability but gives user some visibility and control?

See above. Arguably, users already have some visibility and control, if they have an understanding of how their trust store works. 

Granted, the visibility and control afforded generally sucks, but so far the efforts the IETF community has agreed to are about tightening that up (see CT), not providing another (legitimised) avenue for reducing the requirement for end-to-end security.

Also, realise that one of the key differentiating factors is whether the intermediary's cert gets installed separately or automatically. Automatic acceptance of a MITM cert (e.g., perhaps with a click-through dialogue) is asking for attacks; most people will click through that. OTOH if a cert has to be deliberately added to the trust store by the user before they can access a site, that's a very different thing.


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

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 25 June 2014 00:05:08 UTC