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

On Thu, Aug 21, 2014 at 3:29 PM, Eduardo' Vela" <Nava> <evn@google.com> wrote:
> On Thu, Aug 21, 2014 at 2:19 PM, Chris Palmer <palmer@google.com> wrote:
>>
>> On Thu, Aug 21, 2014 at 2:09 PM, Eduardo' Vela" <Nava> <evn@google.com>
>> wrote:
>>
>> >> Can you explain more? What are some realistic public deployment
>> >> scenarios in which TLS is utterly useless?
>> >
>> > Any setup where the network is outside of your threat model.
>> >
>> > Think of the way Chromecast is configured, it's an HTTP server listening
>> > on
>> > a wifi network. You can't distribute a SSL certificate to the device
>> > (there's no internet access yet), and we will hold some web platform
>> > hostage
>> > from them for no good reason.
>>
>> But Chromecast does not (yet...?) serve a web app that wants to run
>> WebCrypto or ServiceWorkers on my laptop. Mostly the laptop casts
>> content to the Chromecast.
>>
>> We should talk about if we should accept an origin as having been
>> securely transported if the user chooses to proceed past an HTTPS
>> warning interstitial page, e.g. for an unknown authority or name
>> mismatch.
>
> This is also part of the problem, the user now will need to pass an HTTPS
> warning interstitial page to be able to use web platform features. We'll be
> punishing the user for trying to use a site that wants to use a hash
> function, smarter caching, or personalize data, even for cases where it adds
> little-to-none security benefit. I totally get it "the needs of the many...
> etc", but I wouldn't say this is a sane trade off.
>
>> I have an idea for how to handle authentication for Internet Of
>> Things, but that's separate from this thread. But we (as an industry)
>> are indeed going to have to figure that out soon. As a fellow security
>> engineer, I am sure you are not advocating a Crunchy On The Outside,
>> Soft On The Inside security posture.
>
> Which is why I am hoping we don't hijack web platform features for anyone.
>
>> > Not all web applications are connected to the internet. Same for VPN
>> > services where you can authenticate at a network level.
>>
>> Or indeed, with a private, organizational CA.
>
> Which they don't need today.
>
> One of the reasons the web is such an attractive platform is because it's so
> easy to setup. Install Apache in your home computer and you've got a
> Website. I used to do it in middle school, and I'm 100% sure I wouldn't have
> been able to buy an SSL certificate (since I didn't even have a domain not
> even no-ip.info)..

You can use AppEngine
(https://developers.google.com/appengine/docs/python/config/appconfig#Python_app_yaml_Secure_URLs)
or AWS (http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html)
to do that today, both with SSL, both free for at least 12 months.

> I suspect the reason Service Workers are limited to SSL is to prevent
> backdooring (as in, go to starbucks once and get your homepage backdoored).
> This is very hard (and in most cases even impossible) with today's web
> platform features, so I get why making Service Workers SSL is a reasonable
> trade off (since otherwise, it puts websites at risk).
>
> I do not get why Geolocation and WebCrypto need to be SSL only. Who are we
> protecting here? The website? Nope. The user? Apparently. Against who?

https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ perhaps.

Received on Thursday, 21 August 2014 22:54:49 UTC