In our recent article on cookie injection vulnerabilities, I briefly mentioned that HSTS could help mitigate the impact. In this article I’d like to take a more focused look at HSTS and how it can help improve security and privacy for web users.
Let’s start with a common attack used against HTTPS connections. Like many people (or many writers, at any rate) I spend a lot of my day in coffee shops and other providers of insecure bandwidth over WiFi. Suppose I wanted to check the balance of my bank account to see it will stretch to another chocolate muffin. I grab my phone, spot what looks like the place’s WiFi network, connect, and log-in to my bank’s site. When I’ve reaffirmed that my mother was right about there being no money in blogging, I logout, and go about my day.
Unfortunately, I wasn’t careful about the WiFi network I connected to, and what looked like the coffee shop’s network was, in fact, a network created by the criminal sat across from me. He acted as a man-in-the-middle, intercepting my communications with the bank, stripping out HTTPS links, and replacing them with HTTP links, relaying my communications to the bank, and the bank’s communications to me, snagging my login details in the process.
You might think the browser would set off alarm bells when this happens, but the browser has no idea which sites should be connected to over HTTPS and which should not. It doesn’t consider it inherently insecure that I’m using plain old HTTP (or at least not yet).
HSTS — the HTTPS Strict Transport Protocol — makes this sort of attack almost impossible (I’ll go into the “almost” soon). HSTS works like this: the first time I connect to my bank on a browser, the site sends a header that tells the browser that all future connections to this site should be secured. That is, the browser should no longer accept any connection from this site that isn’t secured by HTTPS. The header includes a time limit, usually on the order of six months. When the miscreant in the coffee shop tried to strip the HTTPS out of my links, the browser would warn me, and I’d be safe.
Now to that “almost impossible”. If when I first connect to my bank using the browser, before it has received the HSTS header, and my connection is intercepted as explained above, then I’m in the same situation as before. However, that one weakness is still orders of magnitude more secure than using insecure networks without HSTS.
HSTS isn’t at all difficult to implement. For Apache it’s just a simple configuration tweak. So why have such a tiny fraction of sites implemented HSTS? Historically, site owners could argue that browser support was patchy — particularly by that perennial laggard IE. Since earlier this year though, IE joined the roster of modern browsers with support for HSTS, so now the question becomes, if you haven’t implemented HSTS on your site, why not?