What is HSTS? It's advantages in Security and potential for tracking

Govind Narayan Sharma
Govind Narayan Sharma
January 25, 2019
#security

What is HSTS?

The HTTP Strict Transport Security or HSTS (specified in RFC 6797) isn't really a separate communications protocol meant to replace HTTPS. Instead, it's actually a mechanism that forces the proper use of HTTPS and mitigates some of its serious limitations.

To better appreciate the benefits of HSTS, it would be a good idea to discuss those limitations first.

Limitations of HTTPS:-

HTTPS allows you to connect securely to any site. But it is reliant on user correctly entering the url with https:// added before the url.

For example, entering https://www.example.com in browser url bar will force the browser to connect to example.com using HTTPS.

However most users don’t always indicate the protocol (i.e. HTTP or HTTPS) or sometimes even the top level domain (i.e. www). For example if a user want to visit http://www.example.com they will most likely type www.example.com or example.com

However all popular browsers are able to anticipate what the user wants to do and simply add the protocol. So if, say, you type in www.example.com in the browser URL bar, the browser will automatically send the request for http://www.example.com to the web server.

Here we should note that what's normally sent by the browser is http:// and not https://. Thus, if you won't explicitly order the browser to connect via HTTPS, it will simply connect via HTTP by default. And then if the website server has been set to redirect HTTP requests to HTTPS, then after initially connecting via HTTP, all succeeding transactions within the same session will be done over HTTPS.

That’s pretty cool except for one thing. What happens if there is a man-in-the-middle attack on the first connection itself when the browser sends the initial request using HTTP?

Remember that the browser (if no protocol is specified by the user) will initially have to connect via HTTP all the time. There is no way the browser will be able to remember that a particular domain should be connected to via HTTPS. Even if a browser has already connected to a domain over HTTPS, that doesn't mean it will already automatically send succeeding requests via HTTPS when it connects again the following day, week, or month.

How HSTS solves this:-

When a web server implements HSTS, it forces all connecting browsers to use always HTTPS. This removes the initial HTTP connection so there won’t be any scope for man-in-the-middle attacks.

How this works:-

When a browser makes its first ever HTTPS connection (perhaps after the user explicitly enters HTTPS on the URL bar or via HTTP-HTTPS redirect) with a web server that has HSTS enabled, the server will respond with the response header field: "Strict-Transport-Security".

Format for "Strict-Transport-Security" header

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

When the browser sees this header, it will make all subsequent requests to this server using HTTPS and it will continue to do so as long as the max-age field above is not exceeded.

Max-age is the time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS. Usually this value is set for a period of one year, so you should set the max-age to at least 31536000 seconds.

That means, if a browser has just received the Strict-Transport Security field from this server, and it (the browser) attempts another connection the following day, week, or month (or 11 months later), then it will automatically send each URL request in HTTPS.

What's more, even if a user (using the same browser in question) clicks a HTTP hyperlink that points to a resource under the same domain, the corresponding request will still be sent via HTTPS.

However even a feature like HSTS which was designed to enhance security on the web can be used for user tracking.

HSTS as a Persistent Cross-Site Identifier (aka “Super Cookie”):-

An attacker seeking to track site visitors can take advantage of the user’s HSTS cache to store one bit of information on that user’s device. For example, “load this domain with HTTPS” could represent a 1, while no entry in the HSTS cache would represent a 0. By registering some large number of domains (e.g., 32 or more), and forcing resource loads from a controlled subset of those domains, they can create a large enough vector of bits to uniquely represent each site visitor.

The HSTS authors recognized this possibility in Section 14.9 of their spec:

“…it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names.”

On the initial website visit:

  • A random number is assigned to the visitor, for example 8396804.
  • This can be represented as a binary value (e.g., 100000000010000000000100)
  • The tracker script then makes subresource requests to a tracker-controlled domain over HTTPS, one request per active bit in the tracking identifier.
  • https://bit02.example.com
  • https://bit13.example.com
  • https://bit23.example.com
  • … and so on.
  • The server responds to each HTTPS request with an HSTS response header, which caches the tracking value in the web browser.
  • Now we are guaranteed to load the HTTPS version of bit02.example.com, bit13.example.com, and bit23.example.com, even if the load is attempted over HTTP.

On subsequent website visits:

  • The tracker script loads 32 invisible pixels over HTTP that represent the bits in the binary number.
  • Since some of those bits (bit02.example.com, bit13.example.com, and bit23.example.com in our example) were loaded with HSTS, they will automatically be redirected to HTTPS.
  • The tracking server transmits one image when they are requested over HTTP, and a different image when requested over HTTPS.
  • The tracking script recognizes the different images, turns those into zero (HTTP) and one (HTTPS) bits in the number, and voila — your unique binary value is recreated and you are tracked!

Attempts to mitigate this attack are challenging because of the difficulty in balancing security and privacy goals. Improperly mitigating the attack also runs the risk of weakening important security protections.

How different browser handle HSTS Super Cookie:-

Firefox:-

Firefox has implemented a way to avoid this by no longer carrying HSTS over to private windows. It is, however, a trade-off - favouring "privacy over security" Greenhalgh writes. If you're trying to buy something from a website using a private Firefox tab and you load an unencrypted version of the page, then it won't correct you - meaning your credit card info won't be encrypted once you send it.

Chrome:-

Originally chrome team decided to carry overs HSTS pins set during normal browsing mode to incognito mode, favoring security over privacy, as Technical analysis of client identification mechanisms chromium document mentions:-


 “It follows that a fingerprinting server could set long-lived HSTS headers for a distinctive set of attacker-controlled host names for each newly encountered browser; this information could be then retrieved by loading faux (but possibly legitimately-looking) subresources from all the designated host names and seeing which of the connections are automatically switched to HTTPS.

In an attempt to balance security and privacy, any HSTS pins set during normal browsing [were*] carried over to the incognito mode in Chrome; there is no propagation in the opposite direction, however.”

However this behavior was changed in Chrome 64, such that Chrome won't use on-disk HSTS information for incognito requests.

Safari:-

To prevent tracking codes from using an array of websites to set HSTS instructions, Safari now blocks HSTS instructions from everything other than the site you’re on, or its root domain (or the Top Level Domain + 1, as it’s described on the WebKit blog).

So, if you visit tracking.website.example.org then you can only get HSTS instructions from tracking.website.example.org (the hostname you’re on) and example.org (the root domain).

Internet Explorer:-

The good news is you are completely protected from this type of tracking! Now for the bad news: It's because IE doesn't support HSTS at all.

References:-

https://tools.ietf.org/html/rfc6797

https://tools.ietf.org/html/rfc6797#section-14.9

https://webkit.org/blog/8146/protecting-against-hsts-abuse/

https://www.jscape.com/blog/what-hsts-is-and-how-it-enhances-the-effectiveness-of-https

http://www.chromium.org/Home/chromium-security/client-identification-mechanisms

https://hstspreload.org/

chrome://net-internals/#hsts