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

On Thu, Aug 21, 2014 at 3:54 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> 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.
>
Building a cool website will now require a Google account (or an Amazon
account, or a VeriSign account). And in a world without these actors, you
have to bypass SSL warnings.

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

Making geolocation permission not sticky across page reloads would fix that
I assume.