Heartbleed is bad, but you can mitigate its damage, albeit via different approaches for users, admins, and developers
Let's face it: Heartbleed is a bloody mess. Worse, it's a different kind of mess for everyone who has to clean up after it. Administrators, end-users, and software developers will all be confronted with aspects of Heartbleed that each can only deal with alone.
Here's what each of them needs to do to mitigate the threats that matter most to them individually.Users
In some ways users have it hardest since the only measures they can take are entirely reactive. They can't patch the actual sites they use (unless they've actually built them), but users can still do a great deal on their own.
1. Check sites you visit for the vulnerability. When news of Heartbleed first broke, the only way to find if a given site was vulnerable was to check against one of a number of manually maintained lists of vulnerable sites or to use a third-party website that tested for the vulnerability. Fortunately, you don't have to do that by hand anymore as both Firefox and Chrome now have add-ons that can manually check the status of a visited site.
2. Rotate passwords, but only after a site has been patched. This is the tricky part. On the whole, it's a good idea to rotate passwords after any security breach, but only after the breach itself has been closed. Otherwise, it's like changing locks on a door that's never closed anyway. To that end, rotate passwords on affected sites, but only after you're certain Heartbleed is no longer an issue there.
If you're not already using a password manager, this is as good an excuse as any to get set up with one. And if you're using sites that support two-factor authentication of some kind but haven't bothered with it, this is also a good excuse to make use of it.
Users of the LastPass password management service get two -- possibly three -- benefits for the price of one. The service not only manages passwords and syncs them across devices, but even lets you know if services are Heartbleed-vulnerable and whether or not it's a good idea to update the password yet (whether or not the site has patched and it's OK to rotate passwords).
3. Enable certificate revocation checks in your browser. Certificate revocation determines if the SSL/TLS certificates used by your browser have been revoked, which many sites are in the process of doing to avoid reliance on keys that might have been compromised courtesy of Heartbleed. In Google Chrome, this is in Settings: Advanced Settings, under "Check for server certificate revocation." With Firefox, this is enabled by default, so you don't need to do anything. The CloudFlare blog has further notes about the behavior of each browser when dealing with certificate revocation.
1. Patch affected systems. Before you say "duh," the trick is to find out which systems are affected. There may be more of these than you think, since OpenSSL may be employed in ways that aren't exclusively external, client-facing applications. Those are clearly the most important ones, but don't assume the inventory of affected systems ends there. Some Cisco products, for instance, may be vulnerable; ditto for Juniper Networks.
Another, even trickier, example: Microsoft's implementations of TLS in Windows Server systems do not appear to be affected by Heartbleed, but that doesn't mean all software running on Windows boxes is unaffected. Some of that software may implement OpenSSL in its own way and need to be updated separately from anything else.
2. Reissue and revoke certificates. Don't flinch. Reissuing and revoking certificate keys is dirty work, but it needs to be done, and even (especially!) big outfits like Akamai have started that difficult job since compromised certificates have to be revoked within 24 hours. Make sure the new certificates are properly credentialed and follow proper guidelines; don't end up like PayPal, which had some of its new certificates issued in the wrong name ("PayPal, Inc.\0a").
1. Audit your code for the use of OpenSSL. Do an audit on all your own projects to determine where or if you are using OpenSSL, then patch or update appropriately. The bigger the project, the more likely it is to contain some dependency on OpenSSL.
2. Get the changes out there. Make sure any products you've updated can get into the hands of users all the faster. For example, Android 4.1.1 is affected (but not earlier versions of Android), and while Google is distributing patches to its hardware partners, who knows how long it'll take before those patches actually hit affected devices. Don't be like that if you can help it.
3. Consider alternatives to OpenSSL if it's feasible. OpenSSL is not the only game in town; other libraries exist. This isn't to say they're drop-in replacements or won't manifest problems of their own, but now might be the time to think about where they could be of use.