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

On Fri, Aug 22, 2014 at 11:37 AM, John Kemp <john@jkemp.net> wrote:

> 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


"be careful" is useless unless we can describe what care is appropriate.
And we have to describe it concisely and clearly so that users can read and
understand it while it's interrupting the task they want to do.

Do you buy things over the internet? Would you send your credit card data
over a non-TLS connection just because TLS doesn't give perfect security?


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