What is HTTP Strict Transport Security (HSTS)?
HTTP Strict Transport Security forces browsers to make secure HTTPS connections with websites.
HTTP Strict Transport Security has been in the news a little bit lately thanks to Google’s decision to add 45 TLDs to the HSTS pre-load list. So, given the recent attention paid to it, we decided we would give you a rundown of HSTS is and why it’s an effective complement to your current SSL implementation.
Let’s Hash it Out…
What is HSTS?
HTTP Strict Transport Security is a web security policy sent via header, that forces browsers to make secure HTTPS connections when they visit a specified website. This prevents cookie hijacking and protocol downgrade attacks. This is accomplished by setting a Strict-Transport-Security parameter that forces all connections to be made securely and disregards and scripts that attempt to load assets over unsecure HTTP. The header sets a period of time that the paramater applies for.
HSTS is an IETF standards track protocol. It is specified in RFC 6797 after being approved exactly five years ago today, October 2nd, 2012.
There is one security risk inherent with HSTS
There’s one major risk that presents itself with HSTS. Because the STS parameter is communicated in the form of a header, there is still a small window of opportunity to attack during the very first connection – before a browser has had an opportunity to receive the header. It’s a rather narrow attack vector, but with the right tools a hacker could strip down your SSL encryption and steal data or even attempt to phish you.
Again, it’s a small window, but it can be exploited and frankly, any risk you can mitigate should definitely be mitigated. So there is a solution in the form of the HSTS preload list.
What is the HSTS Preload list?
The HSTS Preload list a set of pre-loaded websites that employ HSTS. This effectively closes the window for a first connection protocol downgrade or cookie hijacking. When a web browser arrives at a website on the HSTS preload list for the first time it already knows to only make secure connections.
The only problem with the HSTS preload list is that it can take a while to get on. You’re at the mercy of the browsers as to when they update before you’ll be included on the list itself. With some browsers that’s nearly on a monthy basis – so the wait will only be a few weeks – but for others, it can be months. That’s why Google’s decision to register all of its TLDs on the list is so powerful. Now any website with those TLDs – that is secured with an SSL certificate – is already on the list by default.
Look for plenty of other domain registrars to follow suit in the coming months.
Should I implement HSTS on my website?
Yes. We definitely recommend employing HSTS. Even with an SSL certificate, there are still ways to exploit a site. Especially one that uses 301 redirects to send traffic to the HTTPS versions of its original HTTP pages. Not having HSTS is like putting a nice big padlock on the front door of your website, but accidentally leaving a window unlocked. There’s still a way to get in, you just have to be a little more sophisticated to find it.
So yes, we recommend implementing HSTS. Not only HSTS, but we recommend writing the header with the “includeSubDomains” and “preload” prompts included as well.
Here is an example of a good HSTS header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
What to consider before implementing HSTS
There are a few things worth noting about HSTS before you go ahead and add the appropriate header:
- You must have an SSL certificate installed on your website already
- If you have sub-domains you will need to use a wildcard to protect them
- You must use 301 redirects to reroute all HTTP pages to HTTPS ones
- Google says best practice is two set a max age of two years
- SubDomain and preload headers must be included
Important Note: Just adding “preload” will not get you on the HSTS preload list. You will still need to follow up yourself by going here.
HSTS Header for Microsoft IIS Servers
protected void Application_BeginRequest(Object sender, EventArgs e) { switch (Request.Url.Scheme) { case "https": Response.AddHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload"); break; case "http": var path = "https://" + Request.Url.Host + Request.Url.PathAndQuery; Response.Status = "301 Moved Permanently"; Response.AddHeader("Location", path); break; } }
HSTS Header for Nginx
add_header Strict-Transport-Security 'max-age=300; includeSubDomains; preload; always;'
HSTS Header for lighttpd
server.modules += ( "mod_setenv" ) $HTTP["scheme"] == "https" { setenv.add-response-header = ("Strict-Transport-Security" => "max-age=300; includeSubDomains; preload") }
HSTS Header for Apache Web Server
# Use HTTP Strict Transport Security to force client to use secure connections only Header always set Strict-Transport-Security "max-age=300; includeSubDomains; preload"
How to Sign Up for the HSTS Preload List
To submit your website for the HSTS preload list, you must first satisfy these official requirements:
-
Serve a valid certificate.
-
Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.
-
Serve all subdomains over HTTPS.
- In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.
-
Serve an HSTS header on the base domain for HTTPS requests:
-
The max-age must be at least eighteen weeks (10886400 seconds).
-
The includeSubDomains directive must be specified.
-
The preload directive must be specified.
-
If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).
-
If you satisfy these requirements, simply head here and fill out the form to submit your site to the HSTS preload list.
What we Hashed Out (for Skimmers)
Here’s what we covered in today’s discussion:
- HTTP Strict Transport Security is a website header that forces browsers to make secure connections
- Websites should employ HSTS because it blocks protocol downgrades and cookie hijacking
- We recommend including your site on the HSTS preload list to block a small attack vector with first-time connections
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownPayPal Phishing Certificates Far More Prevalent Than Previously Thought
in Industry Lowdown