HSTS – How To Improve Your Site Security with One Normal, Boring Trick

by Mike Buckbee, Web Security Strategist at Varonis.

(Honestly, You Should Have Done This A While Ago)

The Problem

Security issues in real life can be easy to spot. If you lock your bike up every day with a padlock, you are going to think something is wrong if one day that lock is suddenly missing.

You are much less likely to notice if something changes in your browser. While the big browser makers have greatly improved the UI of security indicators, SSL connection status, and have begun enforcing stricter rules around certificate issuance, it’s still the case that most users won’t notice if the website they visit each day switches from HTTPS to HTTP and is no longer securing their communications.

A browser connecting to your site passes through multiple levels of local networks, ISPs, host routing, and then back again. It is possible for a bad actor at one of those levels to tamper with your request. They can establish themselves as a Man In The Middle (MITM) communicating to your browser in plain HTTP and the server in HTTPS – and this type of activity is referred to as an HTTPS stripping attack.

So, your user will be sitting in their favorite coffee shop, oblivious to the fact that all the credentials and sensitive data they are sending to your site are being sent unencrypted and most likely being intercepted.

The Solution

When browser vendors first realized that this was an issue, they reached for their favorite server-to-browser communication tool, a response header specification. Proposed standard RFC6797 describes a mechanism for “…enabling websites to declare themselves accessible only via secure connections.”

Since they were incredibly smart developers and admins from organizations like Carnegie Mellon, Google, and PayPal, they named the specification something that sounds like you should ask your doctor about, HSTS.

HSTS is an acronym embedded in another acronym and is a mouthful no matter how you unpack it: (Hyper Text Transfer Protocol) Strict Transport Security header. While complicated to explain, improving the security of your site with HSTS often is as simple as adding a single line to your production site configuration.

The Implementation

The response header should be:

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

Sending this from your web server will cause the browser to:

  1. Check for SSL use on the primary domain and any subdomains it was returned from for the next year (that’s 31,536,000 seconds in a year).
  2. Display a warning that is both frightening and difficult to understand – that someone is deliberately messing with their SSL connection (see below).
  3. “Redirect” any connections from http to https.

redirect

More than Redirection

Depending on what parameters you choose to count, 25-50% of sites are now using SSL – which is great and really improves the security of the entire internet. However, at best, perhaps only 10% of those sites using SSL are using HSTS – despite it first being introduced in 2012.

Much of that lack of adoption is likely attributable to people thinking, “I already do that” where they conflate forcing HTTP to HTTPS redirection as equivalent security to HSTS use.

Base 301/302 redirections like adding a RewriteRule to your httpd.conf file (Apache) or modifying the return in your Nginx conf will not protect your users from MITM HTTPS stripping attacks.

As an admin, it is your responsibility to allocate resources, reschedule projects, and coordinate teams to copy and paste the single line of HSTS header configuration into your production server configuration.

Let your Framework Handle It

If you are using a modern web development framework for your site, it is quite likely that a module exists already to make the deployment of HSTS for your site easier.

Despite how simple it is to manually update your web server configuration with HSTS, these libraries are still the preferred implementation method as they typically handle a couple different moving pieces for you:

  • Deploying only in production (you don’t want HSTS in development).
  • Making HSTS host agnostic, you won’t lose your HSTS header if the ops group converts from NGINX to Apache and doesn’t port the entire config.
  • Often, they also implement complementary security features like HTTP only cookies, secured cookies, CSP headers, etc.

References

Node/Express – https://github.com/helmetjs/hsts

PHP/Laravel – https://packagist.org/packages/zae/strict-transport-security

Ruby/Rails – http://guides.rubyonrails.org/security.html#session-hijacking

IIS with .NET – https://serverfault.com/questions/417173/enable-http-strict-transport-security-hsts-in-iis-7/629594#629594

Wrapping It Up

There are no silver bullets in security. There is no one switch that you can flip to magically make your entire stack secure from all threats.

However, by consistently and deliberately folding new security features like HSTS into our applications, we can layer our security (https://www.varonis.com/ultimate-guide-to-layered-security/) and drastically improve from where we are now.

Advertisement