Re: Trusted proxy UI strawman

My own view is that C is unviable.

Until such time as you can prevent malware authors from using HTTPS, 
there will remain significant pressure to decrypt or block https.

Putting all the power in the hands of the browser user is misguided.

The user can always choose not to proceed, and the proxy operator can 
always block.  Those things won't change.  I think the best way forward 
is to provide a framework where the user can make the best decisions, 
and the proxy operator can be the most permissive.

Adrien

------ Original Message ------
From: "bizzbyster@gmail.com" <bizzbyster@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Barry Leiba" <barryleiba@computer.org>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 20/06/2014 3:39:35 a.m.
Subject: Re: Trusted proxy UI strawman

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

Received on Thursday, 19 June 2014 22:26:10 UTC