HTTP Strict Transport Security (HSTS)

Introduction

HTTP Strict Transport Security (also named HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click-through prompts on browsers.

The specification was released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF.

How HSTS Works

Typically, when you enter a URL in the web browser, you skip the protocol part. For example, you type www.acunetix.com, not http://www.acunetix.com. In such a case, the browser assumes that you want to use the HTTP protocol so it makes an HTTP request to www.acunetix.com. At this stage, the web server replies with a redirect (301 response code) that points to the HTTPS site. The browser makes an HTTPS connection to www.acunetix.com. This is when the HSTS security policy protection begins using an HTTP response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The Strict-Transport-Security header gives specific instructions to the browser. From now on, every connection to the site and its subdomains for the next year (31536000 seconds) from the moment this header is received must be an HTTPS connection. HTTP connections are not allowed at all. If the browser receives a request to load a resource using HTTP, it must try an HTTPS request instead. If HTTPS is not available, the connection must be terminated.

Additionally, if the certificate is not valid, you will be prevented from making a connection. Usually, if a certificate is not valid (expired, self-signed, signed by an unknown CA, etc.) the browser displays a warning that you can circumvent. However, if the site has HSTS, the browser will not let you circumvent the warning at all. To access the site, you must remove the site from the HSTS list within the browser.

The Strict-Transport-Security header is sent for a given website and covers a particular domain name. Therefore, if you have the HSTS header for www.acunetix.com, it will not cover acunetix.com but only the www subdomain. This is why, for complete protection, your website should include a call to the base domain (in this case, acunetix.com) and receive a Strict-Transport-Security header for that domain with the includeSubDomains directive.

Threats

HSTS addresses the following threats:

  • User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker

    • HSTS automatically redirects HTTP requests to HTTPS for the target domain

  • The web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP

    • HSTS automatically redirects HTTP requests to HTTPS for the target domain

  • A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate

    • HSTS does not allow a user to override the invalid certificate message

Examples

Simple example, using a long (1 year = 31536000 seconds) max-age. This example is dangerous since it lacks includeSubDomains:

Strict-Transport-Security: max-age=31536000

This example is useful if all present and future subdomains will be HTTPS. This is a more secure option but will block access to certain pages that can only be served over HTTP:

Strict-Transport-Security: max-age=31536000; includeSubDomains

This example is useful if all present and future subdomains will be HTTPS. In this example we set a very short max-age in case of mistakes during initial rollout:

Strict-Transport-Security: max-age=86400; includeSubDomains

Recommended:

  • If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari), then use the header below.

  • Sending the preload directive from your site can have PERMANENT CONSEQUENCES and prevent users from accessing your site and any of its subdomains if you find you need to switch back to HTTP. Please read the details at preload removal before sending the header with preload.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The preload flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.

Is HSTS Completely Secure?

Unfortunately, the first time that you access the website, you are not protected by HSTS. If the website adds an HSTS header to an HTTP connection, that header is ignored. This is because an attacker can remove or add headers during a man-in-the-middle attack. The HSTS header cannot be trusted unless it is delivered via HTTPS.

You should also know that the HSTS max-age is refreshed every time your browser reads the header and the maximum value is two years. This means that the protection is permanent as long as no more than two years pass between your visits. If you do not visit a website for two years, it is treated as a new site. At the same time, if you serve the HSTS header with max-age of 0, the browser will treat the site as a new one on the next connection attempt (which can be useful for testing).

You can use an additional method of protection called the HSTS preload list. The Chromium project maintains a list of websites that use HSTS and the list is distributed with browsers. If you add your website to the preload list, the browser first checks the internal list and so your website is never accessed via HTTP, not even during the first connection attempt. This method is not part of the HSTS standard but it is used by all major browsers (Chrome, Firefox, Safari, Opera, IE11, and Edge).

The only currently known method that could be used to bypass HSTS is an NTP-based attack. If the client computer is susceptible to an NTP attack, it can be fooled into expiring the HSTS policy and accessing the site once with HTTP.

How to Add a Domain to the HSTS Preload List?

To add a domain to the HSTS preload list, the sites for that domain must meet several requirements. Here is what you need to do to add your domain:

  1. Make sure that your sites have valid certificates and up-to-date ciphers.

  2. If your sites are available via HTTP, redirect all requests to HTTPS.

  3. Make sure that points 1 and 2 above apply to all your domains and subdomains (according to your DNS records).

  4. Serve the Strict-Transport-Security header over HTTPS for the base domain with max-age of at least 31536000 (1 year), the includeSubDomains directive, and the preload directive. See above for an example of such a valid HSTS header.

  5. Go to hstspreload.org and submit your domain using the form. If the conditions are met, your domain will be queued to be added.

For increased security, the preload list is not accessed or downloaded by the browser. It is distributed as a hard-coded resource with new browser versions. This means that it takes quite a lot of time for results to appear on the list and it takes quite a long time for a domain to be removed from the list. If you want to add your site to the list, you must be sure that you are able to maintain full HTTPS access to all resources for an extended period of time. If not, you risk that your website will become completely inaccessible.

How to Remove a Domain from the HSTS Cache in a Browser?

When you are setting up HSTS and testing it, you may need to clear the HSTS cache in the browser. If you set up HSTS incorrectly, you may receive errors that will lock you out of the site unless you clear the data. Here are methods for several popular browsers. Also note that if your domain is on the HSTS preload list, clearing the HSTS cache will be ineffective and there is no way to force an HTTP connection.

Removing from Google Chrome

To remove a domain from the Chrome HSTS cache, follow these instructions:

  1. Go to chrome://net-internals/#hsts

  2. In the Delete domain security policies section, enter the domain to delete in the text box

  3. Click the Delete button next to the text box

Afterward, you can check if the removal was successful:

  1. In the Query HSTS/PKP domain section, enter the domain to verify in the text box

  2. Click the Query button next to the text box

  3. The response should be Not found

Removing from Mozilla Firefox

There are many different methods to remove HSTS information from Firefox for a given domain. All of them are described in detail in a dedicated article. The following is the simplest and fastest one, but it removes more than HSTS information from the cache.

  1. Close all open tabs for your site

  2. Open the Firefox history window (Library > History > Show All History)

  3. Search for the domain using the search bar

  4. Right-click the domain and choose the option Forget About This Site

  5. Restart Firefox

Removing from Apple Safari

Removing HSTS information from Safari is very easy:

  1. Close Safari

  2. Delete the following file from your home directory: ~/Library/Cookies/HSTS.plist

  3. Open Safari

Removing from Microsoft Internet Explorer and Microsoft Edge

You cannot remove a domain from the HSTS cache for Microsoft browsers. You can only turn off HSTS temporarily in Internet Explorer 11 and only on Windows 7 or Windows 8.1 (not on Windows 10). Full instructions are available in the relevant Microsoft support article.

Reference

https://www.acunetix.com/blog/articles/what-is-hsts-why-use-it/

PreviousSecurity headersNextContent Security Policy (CSP)

Last updated