Yes, Trust In The PKI Is Broken

The trust in digital certificates relies on the fact that the authority issuing the certificate has validated the identity of the person or company making the request and that the digital certificate can't be forged. New <a href="http://www.win.tue.nl/hashclash/rogue-ca/" target="_blank">research</a> presented at the <a href="http://events.ccc.de/congress/2008/" target="_blank">25th Chaos Computer Congress</a> shows that forging digital certificates is possible and practical. Trust in the SSL i

Mike Fratto, Former Network Computing Editor

December 30, 2008

4 Min Read
InformationWeek logo in a gray background | InformationWeek

The trust in digital certificates relies on the fact that the authority issuing the certificate has validated the identity of the person or company making the request and that the digital certificate can't be forged. New research presented at the 25th Chaos Computer Congress shows that forging digital certificates is possible and practical. Trust in the SSL is now broken.SSL digital certificates are signed by certificate authorities, or CAs. When you go to an SSL-enabled Web site, the browser checks to see if the certificate was signed by a certificate authority contained in the browser. (To see a list of trusted CAs in Firefox, go to Tools->Options->Advanced->Encryption->View Certificates then click on Authorities for CAs and Servers for self-signed certificates. In IE7, go to Tools->Internet Options->Content->Certificates then Intermediate or Trusted Root Corticated authorities.) If the CA certificate exists and everything else checks out with the Web server certificate, then the browser "trusts" the certificate. Otherwise you get various warnings about validity. Those warnings, by the way, indicate a failure and you should NOT trust the certificate or the site.

Through the power of public key cryptography, there should not be a way to forge a digital certificate. But any cryptography eventually will be broken, rendering it useless. In this case, the algorithm used to sign certificates, MD5, has been shown to be weak as far back as 2004, but even earlier, in the late '90s, there was a call to move to the stronger SHA-1 algorithm.

Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger have found a way to forge digital certificates issued by CAs that use MD5 to sign certificates. The forged certificates will be trusted by your Web browser and can be used to impersonate a legitimate Web site certificate regardless of who issued the authentic certificate. Their paper, "MD5 Considered Harmful Today: Creating A Rogue CA Certificate," and their presentation slides provide a thorough explanation of how the attack works. Jennifer Jabbusch has a more concise description. Suffice it to say, all it takes is one trusted CA cert that uses MD5 and the trust in a PKI falls apart.

Amazon.com's SSL certificate is signed by VeriSign. An attacker could, for example, forge a certificate from a CA that uses MD5 such as RapidSSL or Thawte so that the forged certificate appears to identify the rogue site as amazon.com and will be trusted by your Web browser. Now all the attacker has to do is redirect your browser to the Web server he controls using any number of techniques, and you have a transparent man-in-the-middle attack. There's nothing Amazon or VeriSign can do to stop this from taking place.

The researchers posit that it might take a month for a knowledgeable group to pull off a similar attack and longer for a group less knowledgeable. I think they are being optimistic. Where there is money to be made, like in phishing and forging, the criminals will follow, and they're well funded and can hire talented staff.

There are a few ways to mitigate the potential problem:

  • You could simply go through your browser's trusted CA list and delete any CA certificate that uses MD5. Then you will get warnings about certificates that are issued from those CAs. I don't recommend you do that because you could cause more problems for yourself than not.

  • CAs still using MD5 to sign certificates should stop doing so. Now. They should also reissue any certificates using SHA-1 to sign the certificates and revoke any signed by MD5. They should do this for no cost to their customers since they are putting the rest of the world at risk.

  • Browser vendors should implement checks in their browsers that will pop up a warning when a certificate signed using MD5 has been presented. Just because a certificate is signed using MD5 doesn't mean it is a forgery, but it is certainly possible.

I'm not a fan of Extended Validation Certificates because the marketing messages pushing them are largely disingenuous. But I do think standardizing certificate issuance and CA operational practices is a good and valuable goal. In this case, the Extended Validation Certificate guidelines requiring the use of SHA-1 forces Extended Validation CAs to not use the weaker algorithm. Of course, forging MD5 signed digital certificates isn't the only way to get a rogue certificate. For example, CA resellers may not follow proper procedures for granting certificates or a CA may be duped into issuing fraudulent certificates, as happened to VeriSign in 2001.

The trust we place in PKI has always been on shaky ground. That it works is more a matter of luck than good engineering. This case simply highlights that even one component can bring the whole system to its knees.

About the Author

Mike Fratto

Former Network Computing Editor

Mike Fratto is a principal analyst at Current Analysis, covering the Enterprise Networking and Data Center Technology markets. Prior to that, Mike was with UBM Tech for 15 years, and served as editor of Network Computing. He was also lead analyst for InformationWeek Analytics and executive editor for Secure Enterprise. He has spoken at several conferences including Interop, MISTI, the Internet Security Conference, as well as to local groups. He served as the chair for Interop's datacenter and storage tracks. He also teaches a network security graduate course at Syracuse University. Prior to Network Computing, Mike was an independent consultant.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights