SSL Crack Shows You Must Advance Your Security

It’s just one embarrassment after another for the digital certificate business lately. First, lax procedures at a Comodo affiliate resulted in the sale of a “mozilla.com” certificate to someone unaffiliated with that group. Now a more serious technical problem has developed with the way some certificates are generated, but the real problem is still human.

It was announced at the Chaos Computer Congress in Berlin held 27th to 30th December : A practical collision attack on MD5 hashes, called a colliding certificates attack, allowed a group of brilliant attackers to create a signing certificate for a legitimate certificate authority. Click here for the paper they wrote on their research.

Popular Web browsers and many other applications are distributed with the root certificates of trusted certificate authorities so that the browsers can verify that Web site certificates they encounter were, in fact, issued by one of the trusted authorities. By creating their rogue certificate, the researchers were able to create certificates that would be verified by Web browsers as having been issued by the legitimate certificate authority, which, in this case, was RapidSSL, a low-cost CA owned by VeriSign. The researchers revealed enough of their research to make the problem clear and to demonstrate that they did what they claimed to do, but not enough, for now, to allow others to replicate the work quickly.

The research is brilliant and the researchers handled themselves so well that they have received nothing but applause, even from VeriSign, which acknowledged the problems that allowed the colliding certificates attack and is moving swiftly to remove them from all of their certificate products. Any customer with an affected certificate can have a new, unaffected one, issued for free by the company.

Before I get to what I believe is the main lesson of this episode, I’ll talk a bit about hash functions, the target of this attack. Hash functions are used to take a block of data, potentially large, and to create a value from it on which other operations may be performed. A hash function will always create the same hash for the same block of data, but you don’t want it to be practical to reverse the process and create the data block from the hash. And while it’s certain that, somewhere in the world, there are two blocks of data that create the same hash, you don’t want it to be practical to find them.

This last problem is what happened in the colliding certificates attack: The researchers used a cluster of 200 PlayStation 3s to find a hash collision for the RapidSSL signing certificate.

The hash function used in this case was MD5, a rather old function, and one that has been known for years to be subject to collision attacks. Other CAs found by the researchers to still be issuing certificates using MD5 hashes are FreeSSL, TC TrustCenter, RSA Data Security, Thawte and Verisign.co.jp. There have been a series of improved functions introduced over the years, the most famous and common one being SHA-1.

In all likelihood, the non-MD5 certificates the researchers found used SHA-1, and yet these are not safe either. Other research has shown that SHA-1 is probably vulnerable to collision attacks as well, and it’s just a matter of time until improved algorithms and faster PlayStations make SHA-1 crackable.

There is a stronger SHA-2 version that uses variable-length keys and thus can be designated as SHA-224, SHA-256, SHA-384 and SHA-512. NIST, the National Institute of Standards and Technology, is holding a competition for a new hash function, to be designated SHA-3, to set a new standard for the future. One submission in the contest is Skein, by Bruce Schneier and many colleagues.

At one level, changing hash functions is easy, but as a practical matter it’s a headache. It’s like saying that we’re going to be switching from Phillips-head to square-head screws, and that you can’t use Phillips screwdrivers after some time. It means you have to pull out all the old Phillips screws too. They’re everywhere, in places you’ve forgotten about. The first thing you have to do is stop using the old ones, and this research will probably end the use of MD5 hashes by certificate authorities in very short order, although it’s kind of shocking that they were being used at all. Microsoft’s SDL (Security Development Lifecycle) urges users to avoid old hashes and to use SHA-256 or later functions.

In reaction to this research, and to the mozilla.com certificate scandal, some people scoff at certificates as “security theater” and claim they don’t help even when they work as advertised. I think that’s an overreaction and an unhelpful attitude. EV-SSL (which does not allow the MD5 hash) helps by putting the certificate details more in the user’s face. It’s true that SSL (Secure Sockets Layer) needs more improvements like this so that it can deliver something closer to what people think it delivers. That too will take time.

What does it all mean? The most important lesson of all this is not anything specific about SSL or certificates, but that security standards evolve and users have to move with them. The notion of “If it ain’t broke, don’t fix it” doesn’t work well with security because things are often broken even if there appears to be nothing wrong with them.

I see the same reluctance to change everywhere, including from people who think Internet Explorer 6 is just fine and that Microsoft should continue selling Windows XP forever. With very few exceptions, old software products are insecure ones, and there are limits to what you can fix by patching them. Sometimes you need to throw out the old and move forward.