Why Websites Need HTTP Strict Transport Security (HSTS)

HTTPS has become the protocol of choice for any serious website, but effectively enforcing the use of HTTPS instead of HTTP requires the HTTP Strict Transport Security header, or HSTS. By sending the HSTS header with suitable parameters, the server informs the visiting browser that only the HTTPS version of the requested site is available, and plain HTTP will not be served. To avoid redirects at the start of every visit to the site, the browser remembers this information for the duration specified in the response header. In this article, we will look at the history of HSTS, see how it works and how to set it up, and learn why using it can actually drive traffic to your website.

Just Serving HTTPS Is Not Enough

HTTPS was introduced to allow secure communication – something the plain-text HTTP protocol was never intended for. To ensure end-to-end security, all communication between the client and server must be encrypted, but prior to HSTS, there was no way for websites to enforce encrypted communication or indicate that only HTTPS is supported. This left users vulnerable to man-in-the-middle attacks with SSL stripping (as demonstrated in 2009 by Moxie Marlinspike), where the attacker intercepts the browser’s request for an HTTPS page and forwards it to the server as a request for plain HTTP. The user is then served plain-text HTTP content which the attacker can easily view and manipulate. Although the user could then see that only HTTP was being used, without HSTS there was no way to determine if the connection should have used HTTPS in the first place.

In 2012, the IETF published the HTTP Strict Transport Security (HSTS) specification as RFC 6797 to address this gap in the HTTPS encryption chain. Currently, all major web browsers support HSTS. The Strict-Transport-Security HTTP response header allows servers to indicate that content from the requested domain will only be served over HTTPS. When this header is specified in web server responses, any attempts to fetch the plain HTTP version of the site are redirected to the HTTPS version, with no tolerance for certificate errors. To avoid redirects during future visits, the server also indicates how long the browser should remember the site as HTTPS-only. Let’s see how this works in practice.

How HTTP Strict Transport Security Works

Most users don’t specify the protocol in URLs typed into the address bar, so if you request www.netsparker.com (or just netsparker.com), the browser will assume the default HTTP protocol and send an HTTP request to http://www.netsparker.com. Because the Netsparker site uses HSTS to enforce HTTPS-only communication, it responds with a redirect to the HTTPS site (301 response code) and includes the Strict-Transport-Security response header to indicate that only the HTTPS version of the site will be served.

The Strict-Transport-Security header can specify three directives:

• max-age is the only mandatory directive and indicates how long the browser should remember that the site is HTTPS only. The max-age value is given in seconds, so the typical expiry periods of 1 or 2 years correspond to 31536000 or 63072000. If max-age is 0, the browser will forget the site and treat it as a new one on the next connection attempt.
• includesubdomains is optional and indicates that HTTPS is also required for all subdomains of the specified domain. For maximum security, the HTTPS redirect with the Strict-Transport-Security header should include the includesubdomains directive and reference the base domain (e.g. netsparker.com), so all its subdomains (especially the www subdomain) are covered by HSTS.
• preload is also optional and indicates that the site meets requirements for HSTS preloading and is on the HSTS preload list or has applied for it – see below for more information on preloading.

As soon as the browser receives a response with Strict-Transport-Security, it knows that it must use only HTTPS for that site during the entire max-age period. If HTTPS communication is unavailable, for example because HTTPS is not set up properly or a certificate has expired, the browser must terminate the connection. From now on, every time you visit this site, your browser will automatically send an HTTPS request, regardless of the protocol you specify – netsparker.com and http://www.netsparker.com will both direct you to the HTTPS site. Apart from increasing security, this also improves load times, since you don’t have to wait for the server’s redirect response every time you request a URL without entering the https:// prefix.

Preloading: a Remedy for the Bootstrap Vulnerability

Once the browser has set up HSTS for a site, all communication with that site will use HTTPS, which eliminates the SSL stripping threat and guarantees secure transmission. But the first time you visit an unknown site, the browser relies on the server’s responses to determine the correct protocol – this is the Trust On First Use principle (or TOFU for short). Attackers or malware could intercept this first visit to redirect you to an insecure website using a man-in-the-middle attack. This is not as rare as it seems – it just means that the site is not present in the browser’s HSTS database. While this can be the result of a time-based attack via NTP, it can also happen if the max-age expiry period since the last visit has passed, the browser is a fresh install, the server is misconfigured (for example max-age was left at 0 after testing) and so on.

To remedy this and to improve page load speeds, all major browsers (including Chrome, Firefox, Internet Explorer and Safari) contain hard-coded lists of known HTTPS sites. This is called preloading, and is based on the Chromium (Chrome) HSTS preload list. If a site is listed, the browser always connects to it using HTTPS, even on the first visit. This effectively eliminates the only significant vulnerability in HTTPS enforcement, ensuring end-to-end encryption. The only weak point is that the updated list is only distributed with new browser versions, so the update process is slow and if you added your site recently, there is no guarantee that any individual browser installation will already have your site preloaded.

To add your site to the list, first make sure that it meets all the requirements for preload submission:

• Present a valid certificate
• Redirect all HTTP requests on port 80 to HTTPS
• Include the HSTS header in any additional HTTPS redirects
• Serve all subdomains over HTTPS
• Specify all header directives: max-age must be at least 31536000 seconds (1 year), and includesubdomains and preload must be present

When you’re sure everything that everything works, has been thoroughly tested, and all requirements will continue to be met in the future, you can submit your site to the preload list and start including the preload directive in your HSTS response headers. Remember that by adding the site to the preload list, you are telling browsers to only use HTTPS, so any misconfiguration or invalid SSL certificate can result in your site becoming completely unavailable to users.

With properly implemented preloading, HSTS can ensure that a browser initiates and uses only secure connections to HTTPS-serving sites. Of course, the number of secured websites continues to grow, so it’s clear that preloading is only a temporary solution – at some point the static list may become too large to maintain and distribute.

NTP Attacks on HSTS

For the present, HSTS is a fairly robust way of enforcing HTTPS connections. The only practical approach to compromising HSTS is based on attacks against the Network Time Protocol (NTP) that attempt to manipulate system time by faking time values from NTP servers. This allows attackers to fool the browser into expiring HSTS entries and allowing insecure HTTP connections. Note that this is not a problem intrinsic to HSTS – NTP vulnerabilities can also be used for attacks against other security technologies and protocols, including SSL/TLS, Kerberos and Active Directory.

Browser Tracking Using HSTS Supercookies

Implementing HSTS has also introduced a potential privacy issue related to browser fingerprinting. Because each browser stores a separate database of known HTTPS-only sites, attackers can use specially prepared sites to fingerprint the browser by checking its reaction to a suitably large number of requests to domains controlled by the attacker. 

For example, a website might contain multiple single-pixel beacons, each requested over HTTP from a different subdomain controlled by the attacker. By specifying or omitting HSTS headers in specific replies, the attacker can store a potentially unique pattern in the browser’s HSTS database, in effect assigning a fingerprint. When the browser visits the site again, it will attempt to use HTTPS to load the beacons that initially had the HSTS header in replies, and plain HTTP for the remaining ones. By reading this pattern, the attacker can identify and track the returning browser. No cookies are used, and fingerprinting works across multiple sessions and regardless of incognito mode, so these identifiers have been dubbed “supercookies”.

Figure 1. Browser fingerprinting based on HSTS behaviors

How unique this fingerprinting is depends on the number of beacons used. Each beacon provides 1 bit of information, so with 5 beacons you can get 2^5 = 32 values, but increase this to 30 beacons and you have 2^30 – that’s over 1 billion unique identifiers. Attackers can also reset bits previously stored in the browser by sending max-age=0 in the response header, giving them the ability to store multiple bits of information in your browser many times. While it seems that at present this vulnerability is largely theoretical and not used in the wild, it’s good to know about it, as there is no way around it without changing the HSTS spec.

Benefits and Caveats of Enabling HSTS

For users, the obvious benefit of deploying HSTS is improved security through true end-to-end encryption for HTTPS communication. HSTS headers are only valid over HTTPS connections, so using HSTS guarantees that no unencrypted HTTP traffic is sent. Combined with preloading, HSTS also improves page load times by eliminating server redirects from HTTP to HTTPS. Because page loading speed is a vital part of the user experience, especially with mobile devices, faster loads can improve a site’s SEO metrics and drive more traffic your way – so enabling HSTS and preloading makes good business sense.

On the flip side, any HSTS deployment must be carefully planned and considered, especially if you use preloading. Remember that after you enable HSTS, any attempts to connect to your site or web application using plain HTTP will be rejected, and any configuration issues on your web server (such as an expired certificate) might render the site completely inaccessible. You also have to use HTTPS for every single page in your domain and all its subdomains (if you specified includesubdomains), which for complex sites might require additional work.

By enabling HSTS, you are committing yourself to maintaining HTTPS and meeting all preloading requirements continuously and for a potentially indefinite time. However, if you can ensure this and your business model supports HTTPS-only operation, the benefits from improved security and user experience can be significant.