Everybody is writing about Heartbleed this week. The reason? It probably affects more people than any other vulnerability we've ever seen. If you ever log into any web site, anywhere, your password might be revealed -- and that is just the start. The biggest problem? Nobody really knows if somebody actually used this attack.
Well, ok, if you're an attacker who used it, you know it was exploited. It's certainly possible that nobody discovered this flaw before it was found and released -- but it's very hard to prove a negative, to prove that it didn't happen.
And given that this vulnerability was out in the wild for 2 years, it's very possible that somebody found it and used it for their own malicious purposes -- and some media outlets suggest the NSA has known about it all along.
In short, it's best to assume that all your passwords have been compromised, and you should change them, everywhere. If you use the same password in a bunch of places, it might be time to stop doing that, get a password manager (KeePass is a good one, complete with an Android version), and for passwords you need to remember, generate strong memorable ones.
But wait, there's a lot more you should understand. Read on for some Frequently Asked Questions...
Freelock hosts my site. Am I affected?
Freelock production servers are a mix of Ubuntu 10.04 and Ubuntu 12.04. Ubuntu 12.04 ships with a version of OpenSSL that is vulnerable. Ubuntu 10.04 shipped with an older version of OpenSSL that was not affected. Sites hosted on Ubuntu 12.04 -- generally those created or migrated since March 2012 -- are most likely on servers that were affected by this vulnerability. We patched this vulnerability on all servers Tuesday evening (April 8). We are working with our site owners who use SSL to replace their certificates and revoke the old ones, in case the private keys for the certificates were compromised.
We have notified all site owners to let them know whether they were on affected servers, and what next steps may be necessary.
Freelock doesn't host my site. Am I affected?
We also patched all of our customers on our Server Maintenance Plan on Tuesday night. We are still reaching out to these customers about whether they need to replace their SSL certificate.
If you run a dedicated or virtual server, you should at least check to make sure your web site is unaffected. Here is a handy tool that will tell you: http://filippo.io/Heartbleed/
If you are not on our server maintenance plan, and would like assistance with this, we would be happy to help!
My site was on an affected server, but I don't use SSL. Do I need to do anything?
Yes -- once you've confirmed that the server has been patched, change your passwords. Any password used on the system during the time the server was vulnerable might have gotten stolen. Even if you don't use SSL, it's likely that something on your server does -- CPanel, FTP-S, OpenVPN, or https on another site on the same server.
For most web sites, the only really sensitive thing is your password, because it can be used to delete/deface/fake content as you. If you use the same password elsewhere, well, you should have learned to not do that by now -- you should probably change it everywhere.
But other than that, this vulnerability should not be especially worrisome to the vast majority of web site owners. Unless...
I have an SSL site on an affected server. What's next?
After the server has been patched, it's strongly recommended that you get an entirely new certificate with a new key. Why? Because it's possible the private key that secures your certificate has been stolen.
Your site will continue to work fine with your original certificate, but if somebody has gotten your site's private key, it opens up two possible attacks:
- Eavesdropping -- SSL encrypts all traffic between your site and the browser, but if somebody has gotten your private key, they can decrypt this traffic and see all the data in plain text.
- Man-in-the-middle, impersonation attacks -- SSL verifies that when you visit a particular domain, that some 3rd party has verified that the site you are visiting is controlled by the actual domain owner. It's possible (and easy in places like public wi-fi hotspots) to hijack a domain and send you to a fake server. In these cases, SSL can alert you that you are not actually talking to the real site -- but if the attacker has your private key, they can impersonate you as well.
So while your SSL certificate will continue to work just fine without replacement, if it was on an affected server it no longer guarantees that traffic to you cannot be decrypted, or that somebody else can't set up a site that spoofs you.
It's best to get an entirely new certificate with a new private key, and then have the old one revoked.
Then change all your passwords.
I don't have a web site. Do I need to be concerned?
Yes. What has people so anxious about this bug is that it completely undermines trust in the Internet. We've relied upon SSL to ensure the secrecy of a transaction that contains credit card details or social security numbers, and to verify that we're connecting to who we think we're connecting to. Now that's not entirely the case.
As long as every site you connect to using SSL replaces their key and certificate, you can in fact trust that the encryption is working, at least as well as we all did before the Heartbleed vulnerability became known. However, the identify verification part still relies on one more step -- revoking any old keys and certificates that might have been stolen.
The problem here is in how we come to trust an SSL certificate. This works because a third party "certificate authority" vouches for every valid certificate. Your browser is set up to trust any signature "signed" by a specific set of certificate authorities. SSL web sites pay these certificate authorities to vouch for them, and sign their SSL certificates. So now there's millions of signed certificates in the wild, that every browser trusts. If any of these have been stolen, it's possible for somebody to set up a fake site with that stolen certificate.
There is a process for "revoking" a certificate, which basically involves telling the Certificate Authority that a particular certificate is no longer valid. The problem is, these revoked certificates get added to a specific blacklist, and we've never had to blacklist millions of certificates at a time -- so nobody really trusts that all browsers will properly check the revocation list, or even that certificate authorities can handle that many.
It may come down to sending updates to browsers to revoke the actual certificate authorities, and start over with brand new ones -- which would mean having to re-issue just about every SSL certificate on the Internet.
That is why this is such a big deal.
So here's the bottom line: In the next week or two, after everybody has patched their servers and replaced their certificates, you can probably trust the encryption on an SSL connection to keep sensitive data secure in transit. But until the certificate revocation list issues have gotten fully worked out, you might not be able to trust that you are really at your bank's web site, if you connect through an untrusted network. At this point, there is enough doubt in the identity validation issues that SSL can no longer be considered a trustworthy verification of identity, at least not until/unless all of the certificate authorities have replaced their certificates in everybody's browser. That process could take years.