After Debian's epic SSL blunder, a world of hurt for security pros
Admins: Heal thy certificates
It's been more than a week since Debian patched a massive security hole in the library the operating system uses to create cryptographic keys for securing email, websites and administrative servers. Now the hard work begins, as legions of admins are saddled with the odious task of regenerating keys too numerous for anyone to estimate.
The flaw in Debian's random number generator means that OpenSSL keys generated over the past 20 months are so predictable that an attacker can correctly guess them in a matter of hours. Not exactly a comforting thought when considering the keys in many cases are the only thing guarding an organization's most precious assets. Obtain the key and you gain instant access to trusted administrative accounts and the ability to spoof or spy on sensitive email and web servers.
Security pros have rightfully reacted swiftly to word of Debian debacle. But if you think last week's patch is like most other security fixes, you're dead wrong. Installing it is probably the easiest part of mopping up the resulting mess. Once it's installed, admins will be forced to search sometimes sprawling systems for every key that's ever interacted with the buggy version of Debian and a host of other OSes and applications that relied on it.
Certificates for defective keys will have to be revoked, new keys will have to be generated and, in the case of SSL certificates, registered with VeriSign or another certificate authority. No one knows how many keys need to be replaced, but it could number in the hundreds of thousands or millions. The keys are used for Secure Sockets Layer (SSL) transactions, which authenticate servers handling trusted websites and email, and to authenticate Secure Shell (SSH), which provides encrypted channels between sensitive computers.
The heft and tedium of tracking down, testing and regenerating so many keys, and the cost of paying certificate authorities to register them, has left some people feeling pessimistic about the prospects the problem will be fixed anytime soon.
"There's the pain-in-the-ass factor and then there's the cost factor," says Jacob Appelbaum, an independent security researcher, as he ticks off the reasons he believes organizations will be slow to tackle the problem. Sure, some will make an earnest effort, but "even those people are going to be overwhelmed and patch a lot of their systems but not all of them," he adds.
Sponsored: DevOps and continuous delivery