EFF: Websites Must Use HSTS In Order To Be Secure
April 4, 2014 by Electronic Frontier Foundation
This article, written by Electronic Frontier Foundation technologist Jeremy Gillula, was originally published on the organization’s website on April 4.
You would think that by now the Internet would have grown up enough that things like online banking, email, or government websites would rely on thoroughly engineered security to make sure your data isn’t intercepted by attackers. Unfortunately when it comes to the vast majority of websites on the Internet, that assumption would be dead wrong. That’s because most websites (with a few notable exceptions) don’t yet support a standard called HSTS—HTTPS Strict Transport Security.
Why is lack of HSTS even an issue? To see what could go wrong, imagine the following common scenario. You’re in a coffee shop and you want to check your bank account. You pop open your laptop, connect to the free wifi, load up your web browser, and type in your bank’s URL. No security alerts pop up when you load the page, and there’s even a padlock icon next to the address, so you go ahead and login. Unfortunately, you could very well have just sent your login information to a potential attacker.
The way the attack worked is as follows. When your browser first tried to contact the bank’s server and load its homepage via HTTP, the attacker intercepted the request to connect and prevented it from getting there (perhaps by having his laptop pretend to be that free wifi hot-spot). He then sent your request to the bank’s server himself. When he got the response back (i.e. the webpage to load, the images to display, etc.) he stripped out any links that would initiate a secure HTTPS connection, modified the page so that it would show the padlock icon next to the address (by setting a padlock as the favicon), and sent it back to your laptop. Of course these kinds of attacks have been automated. The result is a page that looks identical in your web browser—the only difference is that it’s not secured, and the attacker can read everything you send to the server and everything that gets sent back.
But why couldn’t your browser detect the attack? The problem is that modern browsers display prominent security alerts only when a website’s security credentials appear suspicious—if a website connects over a secure channel and everything appears OK nothing much happens, and the same is true if the website connects over a normal, insecure channel. Without HSTS, browsers have no way of knowing that a website should be delivered securely, and so cannot alert you when a website that ought to be loaded securely (e.g. your bank’s website) is instead loaded via a normal connection (i.e. the unencrypted version the attacker sends to you instead). HSTS fixes that by allowing servers to send a message to the browser saying “Hey! Connections to me should be encrypted!” and allowing browsers to understand and act on that message.
So why haven’t more websites enabled HSTS? The biggest reason, we fear, is that web developers just don’t know about it.1 Another problem is that support for HSTS in browsers has been incomplete: only Chrome, Firefox, and Opera have had HSTS support for a significant period. This is changing though: we noticed that Apple quietly added HSTS support to Safari in OS X 10.9. For now, Internet Explorer doesn’t support HSTS—which means that there’s basically no such thing as a secure website in IE.
In response to questions from EFF about this situation, a Microsoft spokesperson told EFF that the company would now commit to supporting HSTS in the next major release of Internet Explorer (we aren’t sure whether we have persuaded Microsoft to implement HSTS sooner, though that seems quite likely, and is great news). This means that with the next major release of IE, every major browser will support properly secured websites.
In the mean time, what can users do to make sure their connections are secure? One option would be to use EFF’s HTTPS Everywhere browser extension. HTTPS Everywhere automatically tells your browser to use secured connections on many (but not all) websites that support them; on many domains it functions like a client-initiated equivalent of the serverside HSTS mechanism.
But what if you’re stuck using a browser that doesn’t support HSTS or HTTPS Everywhere, or a website that doesn’t support HSTS? For now all a savvy user can do is to always carefully examine the address of the site you’ve loaded, and verify that it’s secure by checking to make sure it has “https” in the front and is the precise address you want to visit.2 Unfortunately this assumes that you know ahead of time (and remember) whether or not a site should be secure, and are meticulous with every website you visit. This is obviously a huge burden to place on users—it makes a lot more sense to automate the process via HSTS, and it’s about time website operators the world over picked up the slack and did so.