12 Aug, 2019

Is Your Site HSTS Enabled?

by nVisium

HTTP Strict Transport Security (commonly referred to as HSTS) is an opt-in browser security mechanism that lets web site owners declare “Encrypted Communications Only”. The Strict-Transport-Security HTTP header instructs browsers to only communicate with the domain over SSL/TLS for a set period of time (the max-age). HSTS only goes into effect after a browser receives a valid header from the domain. The goal of HSTS is to ensure unencrypted communication is not allowed on your site to mitigate attacks such as SSL-stripping.

The HSTS Header

The max-age parameter value is in seconds; 31536000 seconds equals 365 days. Notice how the above also uses includeSubDomains. This optional parameter informs the browser to force secure communication to the site’s subdomains as well.

Browsers must receive the Strict-Transport-Security header over an HTTPS connection with the domain; HSTS headers over HTTP are not recognized as valid.

Threat Mitigation

HSTS mitigates the following threats.

1. HTTP request to an HTTPS site

For example:

  1. User wants to visit SecureSite.com
  2. User types SecureSite.com into the address bar
  3. Browser automatically appends “http://” making the following request: http://SecureSite.com
  4. Server responds with 301 (permanent redirect) to the following location: https://SecureSite.com
  5. Browser makes request to above URL

The above scenario allows for a man-in-the-middle attack as a result of the unintentional HTTP request to SecureSite.com. An attacker can leverage a tool such as ssltrip to transparently hijack the HTTP request prior to the 301 redirect. HSTS eliminates this attack window as long as the user previously accessed SecureSite.com over HTTPS and obtained the HSTS header.

Even with HSTS enabled, a user’s initial request to SecureSite.com would remain unprotected from attacks. As a result, both Chrome and Mozilla introduced HSTS preload lists. If SecureSite.com is on Chrome’s HSTS preload list, a freshly installed Chrome browser will only allow secure connections to that site, even if the user never accessed it before.

2.  Insecure link referencing an HSTS enabled site

For example:

  1. Forum.com includes a link to http ://SecureSite.com
  2. HSTS will automatically convert the link to HTTPS for the HSTS-enabled site

3. Invalid Certificate

The following would be considered invalid certificates:

  • Self-signed and/or untrusted CA signed certificate
  • Expired
  • Wrong name specified

HSTS displays an error message as shown below. In addition, it will NOT allow the user to override the error message, thus preventing a potential attack by ensuring the victim does not accept the bad certificate.

    Creating an invalid certificate with Burp Suite for nVisium.com


Browser Compatibility

See  http://caniuse.com/stricttransportsecurity for a full browser compatibility table

Enabling HSTS

You can enable HSTS in Apache with mod headers and the following line in your configuration:

Afterwards, restart Apache and test the configuration change:

In Nginx, update nginx.conf:

In Rails, HSTS can be enabled with the following:

Alternatively, you can also leverage the  secure_headers gem with your Rails web app to send an HSTS header.

HSTS Preload Lists


Code repository:

Email Adam Langley to get added to the list:

Update : You no longer have to update Adam. Add your site using using the following:


Code repository:

Firefox does not maintain their own list; instead, they use a subset of Google’s. Firefox only accepts sites on Google’s preload list that have a max-age greater than or equal to 18 weeks (10886400 seconds). See https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ for more information.

Preload List Adoption

The below diagram shows the total number of Preload sites from April 2012 to April 2014:

There was an 84% increase from 2013 to 2014.

Testing HSTS


You might also like:

Get Security Assessment Tips Delivered to your inbox