HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS)

Date: 2017-01-27 15:04:58

This article will give a general overview over HTTP Strict Transport Security (HSTS) and discuss what attacks it tries to prevent, as well as how to use it correctly.

1. Basics: What is HSTS?

HSTS is a HTTP header relating to HTTP security which has two effects:

2. Attack scenarios without HSTS

The two effects of HSTS described above prevent common errors from the user as well as the application which may otherwise compromise the security of the application in case of an active or passive man in the middle.

It is recommended to use HSTS even if the server does not support HTTP or automatically redirects all HTTP traffic to HTTPS itself, as there are still attack scenarios. An active man in the middle can for example intercept original HTTP requests and perform a valid HTTPS request to the server in the name of the user, thus reading the request as well as the reply.

3. How to use HSTS

To use HSTS, all HTTPS replies from the server should set the following header:

Strict-Transport-Security: max-age=31536000

The max-age directive defines how long strict transport security should be enforced by a browser, in this case one year.

Additionally, it is recommended to set the includeSubDomains and preload directives. It is however important to first ensure that the server can support HTTPS on the domain as well as all subdomains now and in the future, as preload is not easily reversible.

includeSubDomains

The first benefit of setting the includeSubDomains directive is that all subdomains will be secured on first visit, even without preload, if the user previously visited the parent domain.

The second benefit is that it protects domain cookies from rogue subdomains, which is why the RFC on HSTS recommends to use includeSubDomains.

It is important to realize that setting includeSubDomains means that all subdomains must support HTTPS with valid, non-self-signed certificates, as the HSTS policy cannot be removed by individual subdomains themselves.

preload

HSTS can only prevent the described attack scenarios if a user has previously visited the domain. The first request will thus always be susceptible to attacks. To protect this first request, preload can be used by submitting the domain to a preload list. All major browsers support these lists and will apply strict transport security even on the first visit.

Even though preload provides a security benefit, it is important to carefully consider using it. As preload is not easily reversible, it must be ensured that all resources are indeed available over HTTPS with valid certificates.

Domains can be submitted to the preload list here. It is recommended to follow the deployment recommendations.

4. Removing HSTS

If it becomes necessary to remove HSTS, the application can set the max-age directive to 0, which will tell browsers to not enforce HSTS. However, for this to work, all browsers that visited the page while HSTS was set must revisit the page with a valid HTTPS request, which must be answered by a HTTPS reply using a valid certificate. If the preload directive was used and should be removed, the steps in the removal guide have to be followed.