Re: Proposal: Prefer secure origins for powerful new web platform features

On 08/22/2014 01:54 PM, Chris Palmer wrote:
> On Fri, Aug 22, 2014 at 7:03 AM, John Kemp <john@jkemp.net> wrote:
>
>> Is that the "example.com" that the user read about in that company's
>> advertisement of their URL? Or is it evilcoffeeshop.com's
>> super-safe-encrypted portal, breaking the SSL connection and presenting the
>> user's browser with a "click OK to keep doing what you wanted to do, but oh
>> by the way you are violating this security policy, or CANCEL because of some
>> cryptic security problem that will stop you doing what you wanted to do"?
>>
>> I'm sorry, but conflating "you are communicating via an encrypted transport"
>> is just not the same thing as being able to say with any kind of authority
>> that you are communicating with the "example.com" you trust to do the right
>> thing.
>
> If you're saying that TLS is fundamentally broken because people can
> click through the HTTPS error interstitial pages, then maybe you could
> help us come up with a secure usability solution. You're right to want
> to look at it as a ceremony and not merely as a protocol
> (https://eprint.iacr.org/2007/399.pdf),

Yes, this is certainly something that has value...

> but at the same time I don't
> think it's fair to condemn the whole effort.

As a method of sharing a session key between two unidentified parties on 
the Internet and then using that key to encrypt data between these 
entities, TLS is an excellent solution.

As a method of authenticating the parties to the encryption, it is... 
less than good.

If you can't authenticate the thing with whom you are communicating 
with, is encryption even helpful?

> Especially since we do
> have methods of coping with bad actors like captive portal operators.
>
> We have HSTS and HPKP as ways server operators can stymie captive
> portals and provide strong authentication even in the presence of
> attackers and confused users. And Certificate Transparency can greatly
> strengthen the weakest parts of the web PKI.

If I interact with an imposter who conducts these security ceremonies 
with my browser, I am still interacting with an imposter.

Don't get me wrong, these extensions do actually mitigate (much more 
specific) security concerns. But they don't provide a way that allows a 
user to "strongly" authenticate an arbitrary server.

>
> But a stricter policy of never allowing people to click through *any*
> interstitials (making them terminal pages instead of interstitial) —
> which you seem to want? — is likely to meet with very strong
> resistance.
>
> Hopefully we all agree that TLS/web PKI is a bare minimum, and that
> we'd all like to see something even stronger. But having any TLS at
> all is most certainly a step forward on the path to that safer world.

I think that saying the world is safer with TLS/web PKI is misleading 
and offers a false sense of security that the technology does not 
support. I think a bare minimum would be "sensitive data are encrypted 
between arbitrary network endpoints" - TLS certainly helps with that.

I might add that it would perhaps actually be better for users if we 
gave them the sense that they are largely *insecure* in knowing who they 
are talking to on the web (and should be careful -- see the "ceremony" 
idea you mention above), and also to state that TLS only protects data 
while in transit between a user's network endpoint and the network 
endpoint with whom they are communicating. It is not a solution (without 
additional context at least) either for authentication of the parties, 
or for ensuring that a user's data remain confidential once transmitted 
to any other party.

Regards,

- johnk

>

Received on Friday, 22 August 2014 18:38:05 UTC