The Debian OpenSSL bug is one to take seriously. The possibilities if you don't are not pleasant to contemplate.
Internet alert systems such as the ISC's Internet Threat Level
and Symantec's Threatcon
may have gone back to "Green," but it's way too early to say the Debian OpenSSL bug has played itself out. I think this is one of those problems that will be exploited for months, if not years to come.
Most of the time when there is a serious security-related bug, those at risk have the job of applying patches as soon as possible, and that can be an imposing enough task. But that's not all in this case. In this case you also have to generate new keys *after* you update the software. And you may need to create new certificates and have them signed by a certificate authority, or deploy them to certificate repository, and you may need to use them to sign other items such as program files.
Rest assured that there are still lots of small ISPs and businesses that are vulnerable. Someone will figure out, rather easily it turns out, that they have the vulnerable keys and crack them.
Then what? The question I haven't seen asked yet in this is what the implications are of having someone exploit your weak cryptographic keys. Here are some scenarios.
I think it's fair to guess that the overwhelming majority of digital certificates are used for SSL (Secure Sockets Layer) for secure Web sites. SSL in such cases is used both for encryption and for authentication, and so those functions could be compromised. Are you surfing an SSL Web site from a public Wi-Fi connection? Other people on the network can sniff your packets and decrypt them. Same deal if they're on the same physical LAN as you; they can sniff the network, and your user names, passwords, credit card numbers and so on are theirs. Oh, and on the subject of encryption, SSL VPNs that use certificates generated with weak keys are also completely vulnerable.
You Didn't Plan to Enjoy the Weekend, Did You?
As for authentication, an attacker could make a much more convincing phishing site by faking up the same certificate as the site. Faking a code-signing certificate is an especially interesting possibility. Or, if I have access to the physical network, I could fake up a client certificate and log in, and then all sorts of inside attacks are possible.
Or if that's not enough, consider this entry from the taint.org blog
discussing the possibility of an SSH worm. Scanning for vulnerable systems over the Internet is easy and fast. Bang, someone's logged into your box, although what account they have and what privileges it has is less clear.
No doubt there are lots of small sites set up by consultants that sit, relatively forgotten because they run perfectly fine, that now have a problem.
If I were running an enterprise that I thought might have vulnerable systems in it, I would do some of the scanning discussed in the taint.org blog and see if I could find any internally, or from the outside.
And if you've got weak certificates issued by VeriSign and you need to revoke and republish, note that VeriSign is offering those services for free through June 30 to those affected by this problem. This also applies to GeoTrust, thawte and RapidSSL certificates. No word yet from other CAs (certificate authority), but VeriSign is the 800-pound gorilla in that market. It's yet another reason to move fast in dealing with this problem. You weren't really planning to take any time off this weekend, were you?
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack