The Heartbleed Bug: what non-nerds need to know

Posted on April 9, 2014

If you work with or around nerds, you may have noticed them running around screaming over the last 24 hours about something called “the Heartbleed Bug.” But odds are they’ve been too busy frantically trying to fix things to explain to you exactly what that is, and whether you, a non-technical person, should be worried about it.

The short answer is: yes. You should be very worried about it.

The Heartbleed Bug is extremely bad. It undermines the very core of the systems we’ve used to provide privacy and security on the Internet for the last twenty years. Even if all you do online is buy things or read e-mail, the odds are very good that Heartbleed is going to bite you. This is not hyperbole; the risk to you is very real, and very immediate.

Because the bug was only made public very recently, most of the coverage of it so far has been aimed at techies, explaining to them what they need to do to patch it up. But there hasn’t been a good explanation for everyday Internet users as to why they should care about Heartbleed, and what risks it poses for them. So that’s why I’m writing this post — to try and provide that. If you’re a professional nerd, this post isn’t aimed at you; we won’t be discussing the exact ins and outs of the bug itself here. What we’ll be doing instead is explaining three things in plain English: what the Heartbleed Bug is, how it probably affects you, and what you should do to protect yourself.

What the Heartbleed Bug is

If you and I want to have a conversation online, and we want to make sure that nobody can eavesdrop on that conversation, we need an encryption mechanism — a way for me to turn my messages into a secret code that only you can decipher. That way, if someone grabs my message on its way from me to you, all they will see is unreadable gibberish; but when you receive it, you can decode it and read what I wanted you to read.

When the Internet first started to take off, no such mechanism existed for online communications. This made a whole bunch of things people wanted to do very badly extremely difficult. Take online shopping, for one; if you’re going to put your credit card information into a Web site, you want to be sure that the only people who can read it are you and the people at the Web site. If that guarantee doesn’t exist, you’re going to be very wary of making that purchase.

Over time, a set of standards emerged to enable encrypted communications online. The first one was called Secure Sockets Layer (SSL), which emerged nearly twenty years ago. Over time, SSL evolved into a more comprehensive standard called Transport Layer Security (TLS).

Today, after two decades of use and improvement, SSL and TLS secure a breathtaking volume of online communications. If you’ve ever connected to a secure Web site and seen the little padlock icon in your browser, for instance, you’ve used them; the padlock is how your browser tells you that your communication with that site has been successfully secured via SSL/TLS. But SSL/TLS isn’t just for encrypting Web pages — it’s a general-purpose encryption technology that’s used almost everywhere a secure connection is needed.

Since all those programs (like my Web site) need to learn how to “speak” SSL/TLS to be able to talk to all the other ones (like your browser), someone has to write programming code to teach them that. And as is common in cases where lots of people have the exact same problem, plug-in solutions eventually emerged, so that those people could just grab something off the shelf rather than having to write all that code from scratch for each new program.

The most popular of these plug-in solutions has long been a set of open-source tools called OpenSSL. Because it is free, reliable, and distributed under a license that makes it easy to roll into other products, OpenSSL has since its introduction in 1998 become the provider of SSL/TLS functionality for a gigantic range of online tools and services. Apache and Nginx, for example, are two popular Web server software packages that between them power something like two-thirds of the Web; they both use OpenSSL to serve secure pages to you. But it’s found in lots of other places as well: email software, instant messaging clients, even devices like smartphones, routers and printers.

The Heartbleed Bug is a bug in this very popular software. Boiled down to its essence, what it means is that, under certain circumstances, it’s possible for an attacker to reach across the Internet into a machine running OpenSSL and grab copies of all sorts of sensitive information — up to and including copies of that machine’s encryption keys.  And that’s a Big Deal, because what makes your encrypted communication with someone else secure is the fact that only the two of you have the key. The key is what lets you take the encrypted gibberish and translate it back into the original, readable message. So if someone else can get their hands on a server’s keys, all “secure” communications between that site and anyone else are suddenly readable by that person.

So that’s half of why Heartbleed is so bad. Here’s the other half: it turns out that this bug has been sitting in the OpenSSL software since December of 2011. So ever since then, for more than two years, all those systems using OpenSSL for their security — e-commerce sites, banks, government sites, mobile apps, devices, etc. — were silently wide open to anyone who knew about the bug.

It is this combination of extremely wide deployment and extremely long exposure that makes the Heartbleed Bug such a big threat.

How the Heartbleed Bug affects you

If you’re not a developer or other technical person, the primary way the Heartbleed Bug will affect you will be through the potential compromise of your usernames and passwords for various online sites and services.

Think about all the sites you log into regularly for a moment. Most of them, I’m sure, take care when they ask you to type in your password to do so on a secure (“https://”) Web page. This prevents bad people from being able to read your password; since it’s encrypted, only the people who have the encryption keys — namely your browser and the Web site operators — can read what you’ve typed in.

Or at least, that’s how things are supposed to work. The Heartbleed Bug complicates things, though, because suddenly that “secure” Web page you’ve been using to log in these last few years turns out to not have been secure at all. An attacker who knew about Heartbleed could, in theory, read your password as easily as if you’d written it on a postcard and mailed it to them.

Oops!

But wait, it gets worse. Because most people don’t use different passwords for every site and service they use — you’re supposed to, but nobody does — once you’ve got their password for one site, it’s likely you can use it (in combination with their email address) to access their accounts on other sites. If the person uses the same password for everything,  getting the password for (say) their Gmail account also lets you into (say) their bank account, and vice versa.

A secondary risk, beyond losing control of your passwords, is that sensitive content that you accessed online may have been viewable by third parties. When you log into your bank’s Web site and download a PDF copy of last month’s statement, your whole session is supposed to be secure; but if it’s OpenSSL that was doing the securing, it’s possible someone else could have grabbed a copy of that statement too. When you punched your credit card information into an e-commerce site, it may have been viewable too. Email that was supposed to be transferred to you securely could have been read. And so forth.

What you should do to protect yourself

The first thing you should do is change all your passwords. Any password you have used since December 31, 2011, should be assumed to have been compromised.

There’s no way to know if any particular username and password that you use has been exposed due to the Heartbleed Bug. But because it was possible to break into so many sites and services through it for so long, betting that every single site you visited over the last two-plus years managed to avoid getting broken into is, to be frank, a sucker’s bet. The only way to be 100% certain that your accounts are safe is to treat every password you used during that period as if you were sure it has been compromised, throwing them away and creating new ones.

Before you complain that this sounds like a lot of work to do just to head off a theoretical risk, let me assure you that this risk is not theoretical. We know that attackers can use Heartbleed to get access to user passwords and other sensitive information, because security researchers were able to demonstrate doing just that on Yahoo! Mail before that company patched its servers to eliminate the bug. So this is not a hypothetical threat, it’s very real, and you should treat it as such.

The second thing you should do is ask the people who run the secure online services you depend on what they are doing to secure themselves from the Heartbleed Bug.

Changing your passwords is just a stop-gap, not a fix. The only way for the information leakage to really stop is for someone to go into all those sites and services that use OpenSSL and patch that software so that the Heartbleed bug isn’t there anymore. That means that the ultimate responsibility for protecting your personal information rests with the administrators of those sites and services — only they can remove the risk to you completely. If they don’t do that, the Heartbleed vulnerability will still be there, so a bad guy could swoop in and grab your new password just as easily as they did your old one.

(For this reason, you may want to wait a day or two before doing that mass password reset described in step 1 above; that will give the sites you use time to get their systems fixed, so you don’t create a new password only to have it immediately exposed.)

While most of the buzz so far about Heartbleed has been around the risk it poses to big-time online services — Google, Amazon, Yahoo!, and so forth — these are actually the ones who are most likely to get their systems secured quickly; lots of very smart people work at those companies, and they all know they’d be out of business in a month if the world stopped trusting their security. They’ll be burning the midnight oil to get Heartbleed expunged from their systems.

Don’t worry so much about them, then. Worry, instead, about all the smaller online systems you depend on. Most people have lots of these in their lives: the intranet on their network at work; the online time tracker service they use; the Web forum where they argue about My Little Pony episodes. These are the sites that are going to be slow about updating to fix Heartbleed, either because the people running them don’t understand the problem, don’t have the technical chops to fix it, or just don’t think it’s worth their time and effort to do so. You want to know which sites are taking that attitude towards Heartbleed, so you can run away from them as fast as you possibly can.

To that end, you should feel absolutely comfortable aggressively asking your friendly office network administrator, tiny software vendor, Web forum admin, or really anyone who manages a system that does anything over a secure (look for the padlock!) connection if they know about Heartbleed, if their systems were exposed to it, and what they’re doing to deal with that. Don’t take no for an answer! The security of your personal information is important; if you’re doing business with someone who doesn’t see things that way, dump them and do business with someone who does.

Finally, you should keep an eye on your financial accounts, email accounts, and other repositories of sensitive personal information for a while.

While the biggest risk from Heartbleed is that a bad guy used it to grab a server’s encryption keys, there’s the lesser-but-still-serious risk that they managed to grab supposedly encrypted content as well. (Things like that PDF bank statement, or the contents of your email.) For this reason, you’ll want to keep an eye on accounts that could potentially have been compromised in such a fashion, to make sure that (for instance) there’s no weird charges on your credit card bill next month because someone used Heartbleed to swipe your credit card information off your favorite e-commerce site. This is a lower priority, since you probably should be monitoring these accounts anyway, but I mention it under the “better safe than sorry” policy.

Conclusion

So that’s the Heartbleed Bug: it’s very bad, you’re at risk, you should act now to protect yourself.

And then, once that’s done, explain all this to someone else who’s not an alpha nerd — so they can go protect themselves too.

P.S. Why’s it called “Heartbleed,” you ask? It’s because the bug lives in the part of the OpenSSL software that manages the ongoing connection between the server and the software that’s connected to it — the “heartbeat.” With the bug in place, this heartbeat leaks information, and the name follows from that.

UPDATE (April 10, 2014): A follow-up post on this subject — “The Heartbleed Bug is about more than just passwords.”