This is part of our Why HTTPS series.
Simply supporting SSL on your website isn’t quite enough. However, there are two easy and free things you can do to make your setup much more secure: require HTTPS, and enable HSTS. What do these mean? Read on to find out in this second post in the series.
Recommendations
First, let’s start out with the easier of the two recommendations, which is to require HTTPS. If your website supports SSL (that is, if you can go to the https:// version of your website without getting a browser error or warning), then you should require that everyone use HTTPS when browsing your site. Not doing so might reasonbly be compared to having a bank vault with a screen door on the side. If you already have the vault and the vault door, why provide an insecure way in?
The second recommendations is to enable HSTS. HSTS stands for HTTP Strict Transport Security. It’s a way for a website to tell web browsers that they should always use HTTPS when browsing the website, even if they don’t “want” to.
The Scenario
If you’ve seen any spy/war/intelligence/political/etc. movie in the past 20 years, you’ve probably heard someone ask on the phone, “is this a secure line?” Or similarly, “call me back on a secure line.” HSTS, in the world of web traffic, solves this very problem.
To illustrate HSTS with an example in the language of spy movies, let’s say Jack calls the president, and the president immediately says, “call me back on a secure line.” When Jack calls back on a secure line, the president says, “for the remainder of my term in office, never call me on a non-secure line.”
In this example, Jack (the web browser) called the president (the web server). Jack made his initial call (web request) on a non-secure channel (HTTP). The president asked Jack to call him back (a web redirect) on a secure line (HTTPS). When Jack calls back on a secure line (HTTPS), the president says to always use a secure line for a set period of time (an HSTS header), and Jack mentally stores this instruction for next time.
The Problem
This instruction from the president may not seem necessary—what’s the big deal if Jack calls in and is asked to call back?—but let’s introduce the president’s operator to see where a security problem can arise.
In this modified example, Jack calls the president, and the president’s operator answers. Jack says “I need to speak with the president,” and the operator says “please call his secure line at 234-555-6789.” (In our example, the president’s phone number can change at any time, so the standard procedure is to call one “main” number to get the latest number for the president’s secure line.)
Here’s the problem—how does Jack know he was talking to the president’s real operator and not a foreign operative who intercepted the phone call? If that were to happen, then the operator could give Jack any number, and Jack would call it thinking it was given to him by a trusted source. At that point, Jack would call who he thought was the president and might give up classified information to an adversary.
This is exactly what can happen when visiting a website. When a browser makes a request over (non-secure) HTTP, any device between the browser and the server (such as a compromised wi-fi access point) can intercept the request and respond to it “on behalf of” the server (which may never receive the request at all).
This compromised response might be a redirect instructing the browser to go to an entirely different website. And if this other website is designed in such a way as to trick the user into thinking it’s the website he intended to visit, then it may be able to do an extraordinary amount of damage. (Imagine you tried to go to your bank’s website and instead were redirected to a website that looked exactly like your bank’s website but had a slightly different URL in the address bar, like benk.com. Would you notice? Many people wouldn’t, and don’t.)
The Solution
HSTS is a mechanism to prevent the situation above from happening. Here’s how it works: when a browser makes a plain HTTP request for a website (“show me bank.com”), the web server responds with an HTTPS redirect (“call me back on a secure line” essentially). Then, when the browser requests the HTTPS URL the server specified, the server responds with the website and an HSTS flag that says “for the next year, never use plain HTTP to access this website.”
The next time you type bank.com, or click a link to bank.com, or click your bank.com bookmark, even if you try to access bank.com over plain HTTP, the browser will stop you and will automatically make the request over HTTPS. This means that even if someone is between you and the server, they can’t intercept and modify your request or the server’s response, because both are encrypted and can’t be deciphered by the attacker.
An intercepted request followed by a redirect to a different site is known as an SSL stripping attack. It only works with plain HTTP requests, which is why requiring use of HTTPS on future requests mitigates the attack.
(Astute readers may wonder about the very first request made to a website, and they’re right; HSTS on its own, as described here so far, can’t protect an initial HTTP request. There are two main ways of implementing this protection: for browsers (via a plugin or a built-in behavior change) to automatically try HTTPS first, or for you to add your domain to the HSTS preload list, which ships with browsers, meaning your HSTS settings are present for everyone, regardless of whether they’ve ever been to your website before or not.)
How We Can Help
If your website is with Banyan Theory, we can handle all of this for you. Both recommendations – require HTTPS and enable HSTS – are included with our Whole-Site SSL addon, which is just $9/mo. Simply click here or email your account manager to get it.
If you’ve already added Whole-Site SSL but haven’t changed the HSTS duration from our default of 30 days, we recommend increasing it to six months or one year. It’s free, and it vastly decreases the chances of an SSL stripping attack for your customers when visiting your website.
If you don’t have a website from Banyan Theory and you’re interested in getting this level of protection on your insurance agency website, check out our pricing, and if you like what you see, sign up and we’ll get started right away.