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:
- HSTS transforms all insecure HTTP requests to HTTPS on the client side
- HSTS prohibits connections when HTTPS warnings or errors occurred
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.
- Invalid certificate: An active man in the middle may send their own certificate to the user. If the user ignores the browser warning, the traffic can be intercepted. HSTS prevents this as it does not allow a user to dismiss warnings.
Using HTTP instead of HTTPS: HSTS prevents any non-HTTPS connections from the user to the server. Even if a user were to try to establish HTTP connections - which could disclose sensitive information such as cookies - HSTS would prevent this. There are two scenarios where a user may use HTTP instead of HTTPS:
- Via user error: The user enters http://example.com or www.example.com into the address bar or saves it as bookmark instead of using https://example.com
- Via server error: The server incorrectly links some resource as http://example.
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:
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.
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.
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.