CS253 Lecture Summaries: Part XII: Real World HTTPS

From Emily Stark and Chris Palmer (Google Chrome team)

Part of Web Security - Stanford CS 253

HTTPS is useful, but not all web traffic is https, browsers still support http, and https is only as strong as the underlying certificate.

Lecture looks at systems on top of https, what worked in the real world and what did not.

Strict Transport Security

Otherwise known as HSTS

Problem: http still exists, if you type ‘example.com’ it will default to http.

Page can load subresource via http. An attacker can interfere with the http response. See China attack on Github.

First attempt: positive UI - show positive lock icon for https.

Didn’t work - people don’t notice the absence of a security indicator in an attack, often misunderstand their meaning.

Next attempt: Strict Transport Security - website opts into strict mode: “I only ever want to be contacted via a secure connection”.

If a site opts in, the browser will rewrite all requests to https. If the browser ever observes an invalid certificate, the browser will not offer the possibility to bypass.

Note the first request to the site could still be http.

How to opt in? Use a response header:

Strict-Transport-Security: max-age=<expire time>; includeSubDomains; preload

Gotchas: No way to include all but a few subdomains - problem for a large org with many subdomains operated by different entity.

How do you set from subdomain to parent? You have to load a pixel or similar from the parent, with the header set.

No way to undo HSTS besides waiting.

HSTS Tracking

HSTS allows websites to set persistent state which can be queried from 3rd party contexts.

If you go to example.com, load an image from facebook facebook can set global state (hsts).

This can be abused, used as part of fingerprinting.

But this can’t be viewed, restricted, or cleared by a user like a cookie.

Here’s how you can do it. User visits shopping site and loads analytics script from an ad network.

ad network assigns the visitor a unique number (eg 110100001), and loads a subresource for each bit set in the identifier. Each subresource sets HSTS for that subdomain.

Now you go to a new site and that is also using the tracking script. It loads the subresources for each bit, checks if HSTS is enabled (ie which upgrade to https), then it knows which id you have.

This was found in the wild, so vendors started to mitigate. No perfect solution though.

Safari - allowed subresources to set hsts only for first-party or the registrable domain.

Also piggybacked on 3rd party cookie blocking, if safari is blocking 3rd party cookies for a domain, ignore HSTS state for that domain when loading subresources.

Chrome plan - forcibly upgrade mixed content (http subresources on https pages). Don’t apply hsts upgrades to subresources where original page was loaded on http.

Preload

Chromium maintain a massive lists of sites who’ve opted in to including their site on a preload list that comes baked into browsers.

Other browsers pull it in. Very difficult to get off the list when you’re on it.

Sites can add the ‘preload’ header to prove they want to be on the list.

How do we get past the massive list? deprecate http? high value sites only? fetch portions of list on demand.