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

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

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?