Heartbleed is a security flaw in OpenSSL, which is the system used to ensure the security of nearly half the websites on the Internet. The flaw gives hackers the ability to gain the security keys that keep the information passing between your Web browser and online servers encrypted, which could let them decrypt information you're expecting to remain secure -- including user names, passwords, and credit card numbers -- and even pose as legit servers. That sounds pretty ominous, so we sorted out what that means for you.
Heartbleed potentially exposes server encryption keys
What is Heartbleed?
Heartbleed is a code flaw in OpenSSL's hearbeat function that lets hackers trick a server into handing over its private encryption keys. With those keys in hand, hackers can decrypt information that's passing between servers and user's computers without any detection. They can also potentially use those keys to set up their own man in the middle server that appears as if its a legit version of the site you're trying to reach, and that would let them collect as much information as they want.
Imagine, for example, a hacker getting ahold of the encryption keys for your bank. They could then intercept and decrypt your secure transactions, get your credit card and bank account numbers, account login and password, and more.
Don't have time to read all of the background stuff on OpenSSL and heartbleed, but want to know what to do to protect yourself? Jump ahead, we don't mind.
Heartbleed and Heartbeat? Give Me Some English, Please
First, a quick overview of heartbeat. In simple terms, it's a bit of code in OpenSSL that keeps your SSL/TLS sessions open with a server instead of timing out and forcing you to start over. SSL and TLS are protocols for the secure connections between your computer and servers that host websites and email.
Now, a little about heartbleed. There's a flaw in OpenSSL's heartbeat feature that hands over information stored in memory when it shouldn't. Hackers can send servers a heartbeat request that doesn't include as much data as it should, and the server responds by handing over random pieces of data stored in its memory, 64K at a time. Send enough malformed requests, and eventually you'll have enough data to put together the encryption keys the server uses for all of its encrypted communication.
Those encryption keys are essentially the keys to the kingdom. Hackers don't have to gain further access to the server to steal data; instead, they simply need to listen in on the data passing between users and the server, and then use the keys they stole to decrypt whatever is in the secure connection.
A Little SSL/TLS Primer
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are the tools that let servers take what would otherwise transmit over the internet as plain text and easy to read data into an encrypted jumble that's meaningless without the keys used to make it secure. Those keys are comprised of two parts: a public key and a private key. Together, they complete a digital signature that includes the information needed to turn the encrypted jumble back into usable data.
Anyone with the private key part of a SSL/TLS connection can decrypt what's passing through a secure connection because they have the part that tells them exactly how to read the encrypted data.
This isn't so much a problem at the user side because they have the public part of the encryption key; instead, it's an issue on the server side because of the code flaw in OpenSSL that can ultimately hand over the private encryption key.
Mac users had a bit of a security scare recently over an OS X iOS flaw related to SSL/TLS that wasn't server-related. In that case, a coding error would let your Mac, iPhone or iPad skip over verifying the encrypted connection. That flaw gave hackers the ability to set up their own fake servers that your computer assumed were legit so they could steal user data without ever involving the actual server or private encryption keys.
Apple patched that flaw in an operating system update, but it doesn't do anything to protect users from the threat that heartbleed poses because it's a server-side issue and not something your computer, tablet, or smartphone can detect regardless of which operating system it runs. In other words, it doesn't matter if you use a Mac, Windows PC, Linux, iPhone, or an Android smartphone.
How Do I Know if My Servers are Affected?
As a users, you probably won't have direct access to the version number for OpenSSL running on the servers you connect to. For that, you'll have to rely on the server host to tell you whether or not they're susceptible to heartbleed. You can also check out the Github list of known heartbleed-susceptible domains.
If you're in charge of an Apache server, you can check your OpenSSL version by running this command:
openssl version
This only tells you which version of OpenSSL you're running. Spoiler: If it's earlier than 1.0.1g, you have a problem. Also, there isn't a way to tell if your SSL keys have been taken, so you should assume they have.
Which Versions of OpenSSL are Susceptible to Heartbleed?
The code bug that makes heartbleed possible was introduced in March 2012, and wasn't patched until April 7, 2014. That leaves two years for hackers to potentially take exploit the flaw.
- OpenSSL versions 1.0.1 through 1.0.1f are vulnerable
- OpenSSL 0.9.8 and 1.0.0 branches are not vulnerable
OpenSSL 1.0.1g, released on April 7, patches the flaw and is already being deployed on Apache servers.
What Can I Do to Protect Myself from Heartbleed?
Server Administrators The real onus for addressing heartbleed falls on the shoulders of Apache system administrators. They need to upgrade OpenSSL to version 1.0.1g, revoke their SSL certificates, generate new SSL certificates and private keys, and get new certificates from their SSL vendor.
After they complete all of that, it's time to notify end users so they can change their login passwords.
End Users and Website Owners You guys are at the mercy of the site hosts, meaning the server administrators. Users can contact the companies they deal with online to find out what they're doing about heartbleed.
Make sure your Mac is set to recognize revoked certificates by setting Keychain Access to recognize revoked certificates. Here's how:
- Go to Applications > Utilities > Keychain Access
- Launch Keychain Access
- Go to the Keychain Access menu and choose Preferences
- Click the Certificates tab
- Set Online Certificate Status Protocol and Certificate Revocation List to Best Attempt
- Set Priority to OCSP
Keychain Access settings to watch for revoked certificates
This will tell every application that relies on your Mac's built-in keychain to avoid revoked certificates. That includes Safari and Mail, as well as many other applications.
Google Chrome has its own settings to monitor certificate validity, but they're off by default. To check for revoked certificates in Chrome, do this:
- Launch Chrome
- Go to the Chrome menu and choose Preferences
- Click Settings, then scroll to the bottom and clich Show advanced settings
- Click Check for server certificate revocation in the HTTPS/SSL section
Chrome's certificate revocation settings
Firefox checks for revoked certificates by default. If you want to double check to make sure that's what's happening, do this:
- Launch Firefox and go to Firefox > Preferences
- Choose the Advanced tab
- Select Certificates
- Click Validation
- Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates should be checked
Website owners should contact their service providers to find out if they are susceptible to heartbleed and whether or not new SSL certificates have been generated. If your site relies on your own SSL certificates, there's a good chance you'll need to generate new ones. Be sure to ask your site host.
If you're a WordPress user, Wordfence has a great post on exactly what you need to do to make sure your sites are heartbleed-proof. Also change your site's password salts to force users to logout.
Short version: Once your host updates OpenSSL, you and everyone else with logins to your WordPress site will be changing passwords.
What Do I Do Once Heartbleed is Fixed?
Until site hosts update their OpenSSL version, there isn't much you can do other than don't log in. Once OpenSSL has been upgraded to version 1.0.1g, it's time to change your passwords.
Just to be clear: You're going to have to change a lot of passwords. Apache and Nginx make up more than half of the Web servers, which means most of your site logins you could be compromised. Even if they aren't, you need to assume they are because there really isn't a way to tell which sites have been hacked.
If you aren't using a password manager, now is a good time to start. A really good time. 1Password and LastPass are both great options.
Is this the End of the World?
Heartbleed is a serious issue and a big pain in the backside, but it isn't the end of the world. Lots of people have plenty of work ahead of them to patch their version of OpenSSL, get new SSL certificates and privacy keys, and change passwords.
Just because someone has an easy way to snatch your encryption keys doesn't mean they have. That said, it's better to be safe and assume your server security has been compromised and act accordingly. For end users, get ready for some massive password resetting - both for site logins and email accounts.