- From: Jim Manico <jim.manico@owasp.org>
- Date: Fri, 22 Aug 2014 10:38:30 -0500
- To: John Kemp <john@jkemp.net>
- Cc: Adam Langley <agl@google.com>, "Eduardo' Vela" <evn@google.com>, Chris Palmer <palmer@google.com>, Mark Watson <watsonm@netflix.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> 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? Overall no, but from a standards-based view? •Absolutely•! -- Jim Manico @Manicode (808) 652-3805 > On Aug 22, 2014, at 9:03 AM, John Kemp <john@jkemp.net> wrote: > >> 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 15:44:57 UTC