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

On 08/21/2014 07:20 PM, Adam Langley wrote:
> On Thu, Aug 21, 2014 at 3:29 PM, Eduardo' Vela" <Nava> <evn@google.com> wrote:
>> I do not get why Geolocation [...] need to be SSL only.
>
> Let's just take this one for a moment. We're giving the web platform a
> fairly significant power here and it's pretty reasonable to want to
> take the sharp edge off it.
>
> When we ask the user whether they want to share their location with
> example.com,

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.

> it's not reasonable to turn around later and say "oh,
> didn't you notice the lack of https? It's thus completely your fault
> that you inadvertently shared your location with example.com and also
> your ISP, government, etc.". We don't want to build a world where that
> sort of information is commonly sent in the clear

I agree that ideally we want encryption between the user's software, and 
the party to which the user actually *wants* to talk to. And what we 
have is encryption between two parties, neither of which can be sure 
that they are talking to who they think they are talking to.

Encrypted data is good, but as security professionals, can we say that 
an encrypted transport has any more worth than, say, unencrypted 
transport, but encrypted payload? Or other mechanisms of ensuring 
confidentiality of data between arbitrary parties?

With the lack of guarantee of actual authentication provided by SSL and 
in the likelihood that this cannot be fixed using traditional PKI 
(without secure software distribution and platforms -- none of which can 
yet, if ever, be guaranteed on the open Web), I think it would be 
helpful if those who want to enforce SSL for everything to provide an 
analysis of what security properties are actually provided by SSL.

A statement that the user is "shar[ing] their location with example.com" 
may be true in some technical PKI sense, but still be completely 
meaningless to a user, and gives a false sense of security that the 
technology does not support.

>
> But the aim is not to make experimentation hard either. It really
> shouldn't be, it's just that setting up a local CA and the DNS for
> experimentation is harder than it should be. If loopback adaptors
> weren't configured by default then HTTP would be a pain to experiment
> with also. If I had lots of free time, I'd submit patches to distros
> to make it easier. But that's a much better direction than a clear
> text world.

Encryption of data intended to remain confidential, between arbitrary 
parties on the Web is probably at this point a generally good idea, I 
agree.

But conflating the security properties of "data confidentiality" between 
arbitrary parties, and "mutual authentication" of two named parties 
should, however, be avoided, *especially* when offering "advanced 
features" to "secure" origins.

Confusing any of these things with "this makes your confidential data 
safe from arbitrary surveillance" is also not a good idea.

OTOH, we don't want to scare users away from the Web; after all, most 
transactions today, whether over cleartext or not, just go fine for both 
the user and the company. And where they don't, shared-liability-based 
models such as that practised by the credit-card industry seem also to 
work reasonably well for all parties.

- johnk

>
>
> Cheers
>
> AGL
>

Received on Friday, 22 August 2014 14:03:56 UTC