Commentary

Mike Fratto
Network Computing  

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 research presented at the 25th Chaos Computer Congress shows that forging digital certificates is possible and practical. Trust in the SSL is now 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 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.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

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.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links