HTTP Strict Transport Security (HSTS) is an opt-in browser security mechanism that lets web site owners declare “Encrypted Communications Only”.
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. HSTS is to ensure unencrypted communication is not allowed on your domain or site to mitigate attacks such as SSL-stripping.
The HSTS Header
Strict-Transport-Security: max-age:31536000; includeSubDomains
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.
HSTS mitigates the following threats.
1. HTTP request to an HTTPS site
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
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
– 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.
You can enable HSTS in Apache with mod headers and the following line in your configuration:
# this domain should only be contacted in HTTPS for the next 6 months
Header add Strict-Transport-Security "max-age=15768000"
Afterwards, restart Apache and test the configuration change:
# curl -si nvisium.com | grep ^Strict
In Nginx, update nginx.conf:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
In Rails, HSTS can be enabled with the following:
# config.force_ssl = true
HSTS Preload Lists
Add your site using using the following:
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.
– Leverage an intercepting proxy (e.g. Burp) or browser tools (e.g. Chrome DevTools / Firefox Developer Tools) to examine server responses
– In Chrome, type the below to determine if a host is in your STS cache
– In Firefox, you can use the Strict Transport Security Detector add-on to see if the site supports HSTS (https://addons.mozilla.org/en-US/firefox/addon/strict-transport-security-d/)