Updated Friday April 11, 2014 with additional info about how the vulnerability affects embedded devices, client software and sites that use hardware SSL acceleration.
This is too long to tweet, so I'm putting it on my blog. This is my understanding of the so-called "heartbleed bug":
- It is a vulnerability in OpenSSL.
- OpenSSL is used for cryptographic security by a wide range of web servers, SSH servers, and basically anything on Linux/UN*X-style operating systems.
- The bug allows someone to potentially have read your private key out of the server's memory without leaving any trace of the attack.
Because the security of all modern network encryption requires that the private key be kept private, that is "extraordinarily bad," as Mr. Spengler would say. But there seems to be some confusion with regard to what needs to be done now to prevent any further damage.
The SSH protocol does not utilize the "heartbeat" feature of SSL and therefore is not susceptible to the bug. So unless you're using the same private key for your web server and your SSH identity for some reason, your SSH keys should be safe. (Unless you're running something that would be a high-value target, where someone might have used a man-in-the-middle attack based on knowledge of your private SSL key to compromise the entire system.) Right?
Web servers are a different story. It is not sufficient just to upgrade OpenSSL to a version that no longer has the bug. Since a vulnerable system has potentially leaked its SSL/TLS private key, it's also necessary to re-key your SSL certificates with a new key, new certificate signing request, and new certificate issued by your SSL certificate vendor. Right?
All of this is terrifying, because the one thing that we take completely for granted in today's computing infrastructure is the unbreakability of cryptography. When something that you rely on completely is suddenly proven not to be reliable, we all suffer.
Note that I do not buy into arguments that this bug implies that open source is inherently insecure. Vulnerabilities like this may have existed in closed-source crypto implementations for years, and you would never have known it. Unfortunately, it also means that just because a piece of security software is open source, doesn't mean that it's bug-free.
Update: Oh Crap
On Wednesday April 9th it became clear to me that it's not just web servers that are subject to this bug.
Embedded Devices. I used Filippo Valsodra's Heartbleed vulnerability checking tool to check the embedded device that we use for a WAN access point, and it proved to be vulnerable. There were no firmware updates available to fix the problem, so I just disabled remote access to the HTTPS management interface. But if you have any kind of "hardware" device that is running Linux or FreeBSD on the inside, it may be vulnerable. Check it, patch it or disable WAN-side remote access, and then change your management password for that device.
Clients. Certain client software is also vulnerable to the bug. I checked all the browsers that I use, and while most of them were not vulnerable, Google Chrome was -- but it only leaks memory 7 bytes at a time, so that's not too bad. Most software I would use or write on the server side links to the OpenSSL dynamic library, so when your system package is upgraded, you've fixed the problem. If any "behind the scenes" client software you may use that statically links a vulnerable version of OpenSSL, you wouldn't know about it being broken, though. Also scary is that certain command-line tools, used in scripts and other server processes, are vulnerable: wget, curl, git, and nginx in proxy mode. (Fortunately, those usually link to OpenSSL dynamically.)
SSL Accelerator Cards. Most large-scale web sites use hardware acceleration for SSL, to offload the difficult math from the CPU to specialized hardware. It was suggested by a few people that users of such accelerators would not be subject to Heartbleed. I'm pretty sure this is not the case, because the way these things work is that OpenSSL handles the protocol, and the hardware does the cryptography. Since the problem is in the protocol and not in the cryptography, doing the cryptography in hardware doesn't help. If the server is/was running a vulnerable version of OpenSSL, there still is/was a problem.
Passwords. Once you've patched/upgraded/disabled/re-keyed, about all that's left to do is a password audit. Go through every username/password on every secure site you've used in the last two years, verify that the site has fixed the vulnerability, change your password, and make sure you are using different passwords on every site. Personally I'm going to start using a password manager, probably 1Password from AgileBits, to generate strong passwords and sync them between the computers and devices that I use.