Digg this story   Add to del.icio.us  
MD5 Hack Interesting, But Not Threatening
Tim Callan, 2009-01-05

A few days ago at the Chaos Communication Congress in Berlin, researchers presented a paper in which they had used an MD5 collision attack and substantial computing firepower to create a false SSL certificate using the RapidSSL brand of SSL certificate. In the intervening time we have seen a great deal of confusion and misinformation in the press and blogosphere about the specifics of this attack and what it means to the online ecosystem.

I hope that this column can clarify many of the issues.

The research revealed a potential attack that required the issuance of new certificates. As explained in SecurityFocus:

The group of researchers took advantage of RapidSSL's fast issuance of certificates. Their attack consisted of creating two certificates and ensuring that the certificates had the same MD5 hash — what is known as a collision. The two certificates consisted of a Web site certificate for a legitimate site and an intermediate certificate authority (CA) certificate that normally identifies a trusted issuer of certificates. Because RapidSSL has an automated script that issues MD5-signed certificates and assigns a sequential serial number and guessable expiration date to the certificates, the researchers were able to fill in the fields of the certificate with the appropriate information and use a distributed computer made up of 200 PlayStation 3 game machines — equivalent to 8,000 standard desktop computers — to calculate the data needed to make the two certificates have identical MD5 hashes. Each attempted attack took less than two days.

The research results are interesting and underscore that certificate authorities (CAs) must move away from the MD5 hash algorithm. The presenters of the paper, however, stressed that it took them a long time and a great deal of computational power to succeed in their collision attack. Considering that it took the original researchers four tries over at least a month to successfully accomplish their attack against the RapidSSL brand, we’re fully confident that no malicious organization had the opportunity to use this information against RapidSSL, or any other certificate authority authorized by VeriSign.

A significant problem with the disclosure of this attack was that we were not given any information on the research prior to its unveiling in Berlin. VeriSign executives and developers viewed the Web stream of the researchers’ presentation live from the conference. Once we were aware of the specifics of the attack, we rendered it ineffective about four hours later. All VeriSign SSL products on all brands are now immune to this attack.

This attack took advantage of several clever bits of hacking to achieve its effect, including the aforementioned highly computational attack on the MD5 hash. As it happens the most expedient and safest method of mitigating the attack was to switch it out for SHA-1. We had been planning this migration to occur on RapidSSL in January 2009 anyway, so we had a high degree of confidence in accelerating that deployment. Other defenses also would have rendered this attack ineffective, including changing RapidSSL’s serial number generation and issuance timing in order to make them less predictable. In the spirit of defense in depth, we’re instituting those changes as well.

We have been in the process of migrating off MD5 for years and will continue on our scheduled plan to discontinue use of MD5 on end-entity certificates by the end of January 2009. It takes some time to phase out a widespread technology platform in a way that isn’t unfairly damaging to the businesses, processes, and individuals that rely on it.

Many have criticized existing certificate authorities for continuing to support and issue MD5-signed certificates. While I cannot speak for other CAs, VeriSign has been working more than two years to migrate the RapidSSL product line to the more secure SHA-1 hash algorithm.

VeriSign acquired GeoTrust in September 2006, at which point we obtained the RapidSSL product line. That was our first opportunity to begin to learn this technology and its platforms and customers. When you absorb a large, established business, a great deal of learning needs to take place, involving much more than a single hash algorithm. There are literally thousands of equivalently important matters to look into, the status of most of them not obvious. Every part of the organization and its people and processes requires investigation, including practices, physical security, authentication standards, process controls, audits, and even the likes of nomenclature and corporate culture.

A good analogy would be if you moved to a new country where they spoke a language you never had heard before and your assignment was to learn the local cuisine and write a cookbook. Before you can even begin working on the cookbook, you have to learn how to speak to people, where the food markets are, and what foods people consider delicacies and what they don't. VeriSign similarly went through a learning process involving every aspect of the business across dozens of product lines, thousands of partners, and hundreds of thousands of established customer relationships.

This process identified a series of changes we wanted to make. We put together a prioritized migration strategy that accounted for a series of factors such as security risk and other potential harms to operators of sites and their customers. We have been continuously executing on that plan since the acquisition, and we’re soon to complete the portion of that plan involving the MD5 phase-out.

While VeriSign has the power to revoke any and all certificates it issues, doing so can be expected to negatively impact their users in a very real financial sense. VeriSign has been running broad scale public security infrastructures for over a decade, and we have established processes for upgrading standards and technologies that are safe, reliable, and seamless to almost everyone involved. These processes ensure that the ecosystem keeps running and that it keeps running safely.

As of today, no action is required by individual site operators. No existing certificates are affected by this attack and the vulnerability has been rendered ineffective for all RapidSSL Certificates moving forward.

In addition, because Extended Validation (EV) SSL Certificates utilize the latest hash algorithm, they are not affected by the just-revealed attack on MD5 vulnerabilities. These security researchers specifically stated that EV SSL Certificates were safe from this attack. They stressed the need for consumers to move to EV-compatible browsers to get the most benefit from extended validation.

As mentioned earlier, we have been engaged in a massive MD5 migration effort for a number of years now and are very near its conclusion. As it is, the overwhelming majority of VeriSign’s certificates are off MD5 today, and the rest are soon to follow. While we can't comment on SSL certificates from other CAs, in general, the industry is managing out MD5, and we consider it unlikely that other CAs will be potential attack vectors in the future.

We applaud security research of this sort and are glad that white hat researchers like these make a point of investigating online security. Fortunately, VeriSign was able to move very quickly to remove this vulnerability.

We have taken the further step of offering to replace, free of charge, any MD5-hashed certificate. Until further notice VeriSign is suspending its normal replacement fees for these certificates. Because this replacement is not necessary to ensure the continued security of sites, we are not requiring the replacement of such certificates, as we have previously with the likes of weak Debian keys.



Tim Callan is Vice President of Product Marketing at VeriSign. He authors a popular online security blog at www.verisign.com/ssl-blog.
    Digg this story   Add to del.icio.us  
Comments Mode:
MD5 Hack Interesting, But Not Threatening 2009-01-08
Charles Hunter (1 replies)
Serious suggestions welcome... 2009-01-15
Robert Lemos


 

Privacy Statement
Copyright 2010, SecurityFocus