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<\/a>. 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.<\/p>\n Let’s Hash it Out…<\/span><\/p>\n 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\u00a0HTTP. The header sets a period of time that the paramater applies for.<\/p>\n HSTS is an IETF standards track protocol. It is specified in RFC 6797<\/a> after being approved exactly five years ago today, October 2nd, 2012.<\/p>\n<\/span><\/span>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u00a0basis – 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.<\/p>\n Look for plenty of other domain registrars to follow suit in the coming months.<\/p>\n 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.<\/p>\n So yes, we recommend implementing HSTS. Not only HSTS, but we recommend writing the header with the “includeSubDomains” and “preload” prompts included as well.<\/p>\n Here is an example of a good HSTS header:<\/p>\n There are a few things worth noting about HSTS before you go ahead and add the appropriate header:<\/p>\nWhat is HSTS?<\/h2>\n
There is one security risk inherent with HSTS<\/h2>\n
What is the HSTS Preload list?<\/h2>\n
Should I implement HSTS on my website?<\/h2>\n
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload<\/code><\/p>\nWhat to consider before implementing HSTS<\/h2>\n
\n