HTTP Strict Transport Security (HSTS): Overview

A while back I asked the question “Is HTTP being left behind for HTTPS?”. If you are looking to make the move to an HTTPS only web space one of the settings you can configure is HTTP Strict Transport Security, or HSTS. The idea behind HSTS is that it will tell the browser to only communicate with the web site over a secure channel. Even if the user attempts to switch to HTTP, the browser will make the change before it even sends the request.

HSTS is implemented as a response header with a few options shown in the below example:

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

In the example above, the max-age (required) is specified in seconds ( a year in this case) and indicates how long the browser should remember this setting. Setting a max-age of 0 will tell the browser to stop enforcing HSTS for the domain.

The includeSubDomains is optional and indicates if HSTS should be enforced an all of the sub domains as well.

You might wonder why this is needed when a user can just go to the HTTPS version of a site. If you watch most users, I am guilty of this myself, they just type the domain of the site they are going to. For example, I might just type developsec.com into the browser. With no indication of which protocol I want to use, the browser will start with HTTP and then the server may respond to switch it to HTTPS. With HSTS enabled, the goal is when a user types http://www.developsec.com or www.developsec.com into the URL, the browser will make the switch automatically.

There are some considerations for this to work as expected. The response header is not respected until the first time you visit the domain using HTTPS with a trusted certificate. Until this happens the browser doesn’t know not to use HTTP. There is a way around this by signing your domain up on the preload list. The preload list can be used by browsers to find out about your domain’s HSTS status before accessing the site. The linked site shows what needs to be done to be allowed on the preload list. Both with the preload list and support for HSTS in general, your browser has the final say. For a list of browsers that support HSTS you can go to the OWASP site.

Self Signed Certificates
One of the security features of HSTS is that tries to block man in the middle (MitM) type of attacks. An attack where your traffic is redirected through an attacker so they can view your data. To do this, HSTS requires the certificate to be a trusted certificate. If it is not a trusted certificate, for example a self-signed one, then you will see the following image indicating it cannot connect:

You may notice that this looks very similar to when you try to connect to a site with a certificate issue with one major difference. There is no way to allow the exception. For testers that use a proxy, such as Burp Suite, you can tell your browser to trust the certificate generated from the proxy tool and it should work just fine.

If you are working toward implementing this feature, make sure you perform appropriate testing to make sure it is working properly. If you use the “includeSubDomains” setting make sure your test environments are using SSL or you may have some trouble shooting to do during testing. If your site is HTTPS only, this is a great feature to add to make sure that your users are only making requests over HTTPS. Hopefully the links included will provide any other information you may need on HSTS.