The Attack

I need to cover this quick. The below paragraph from the white paper was the one which explained what was being done the best.

Our attack scenario basically is as follows. We request a legitimate website certificate from a commercial Certification Authority trusted by all common browsers. Since the request is legitimate, the CA signs our certificate and returns it to us. We have picked a CA that uses the MD5 hash function to generate the signature of the certificate, which is important because our certificate request has been crafted to result in an MD5 collision with a second certificate. This second certificate is not a website certificate, but an intermediary CA certificate that can be used to sign arbitrary other website certificates we want to issue. Since the MD5 hashes of both the legitimate and the rogue certificates are the same, the digital signature obtained from the commercial CA can simply be copied into our rogue CA certificate and it will remain valid.

• Detailed explanation
• Slides from the 25c3 presentation
• Demo site (set your system date to August 2004 before clicking)

Blame

At first, the fault of this attack lies with the certificate authority vendors who have been using MD5 despite several warnings that it was broken. The fault is also partially with us security guys for not ranting harder about the fact that they were using a known broken protocol. However, this is not the first trouble with CAs, for example in the past it has been possible to get certain trusted and lax CAs to issue fraudulent certificates.

How is it then, that we have companies who's sole job is to make sure people are who they say they are and own what they say they do and represent that in the beauty of mathematical cryptographic certainty get one, or the other or both of these wrong?

We have standards and audit procedures for CA's, to name a few (courtesy of Mozilla's CA inclusion policy):

• Annex B, "(Normative) Certification Authority Control Objectives", of ANSI X9.79-1:2001, Part 1: PKI Practices and Policy Framework;
• Clause 7, "Requirements on CA practice", in ETSI TS 101 456 V1.2.1 (2002-04) or later version, Policy requirements for certification authorities issuing qualified certificates (as applicable to either the "QCP public" or "QCP public + SSCD" certificate policies);
• Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V1.1.1 (2002-04) or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to any of the "NCP", "NCP+", or "LCP" certificate policies);
• "WebTrust Principles and Criteria for Certification Authorities" in AICPA/CICA WebTrust Program for Certification Authorities, Version 1.0; or
• "WebTrust for Certification Authorities—Extended Validation Audit Criteria" in WebTrust for Certification Authorities—Extended Validation Audit Criteria (or, for CA requests received on or before June 30, 2008, the November 20, 2006 draft of these criteria) (in conjunction with "WebTrust Principles and Criteria for Certification Authorities").

Let's take Thawte as an example, since they were started by a South African and were fingered in the talk today as one of the vendors who are still using MD5 signing. They are audited annually against the WebTrust Program for Certification Authorities by KPMG. The report for 2007 can be found here, and the certificate here (RapidSSL's is here, both RapidSSL and Thawte are owned by Verisign). Both the reports come out clean. So either the auditors missed this, or the standard doesn't check things as basic as the hashing algorithm. A quick check of the standard makes no specific mention of the hashing algorithm, but generically refers to encryption algorithms as needing to meet the relevant criteria based on a "risk assessment and the business requirements of the CA." Given that no properly conducted risk assesment would highlight MD5 as acceptable, it can be assumed the risk assesment was not proper. So every year since MD5 has been highlighted as broken, the auditors have failed to notice this problem. This slips neatly through the accountability gaps it seems. In the end, here's my blame list in order of decreasing severity:

1. The CAs - it's their business and they need to proactivley secure it, especially when public warning of problems have been given.
2. The auditors - they're paid to validate what the CA is doing, and have specifically reviewed and signed off on the key management practises of most of the affected CAs.
3. WebTrust - a certificate standard needs to be more specific about something as fundamental as a hashing algorithm, and ideally proactivley highlight the risk of MD5 to the CAs and auditors.
4. Every security guy who has received an MD5 generated cert hash and never gone further than thinking "Isn't MD5 broken?" (I'm one of them.)

Solution

There are a bunch of hard, kak, solutions that the CA need to work with. Certificate Revocation Lists aren't implemented well, and at most will provide a reactive solution in cases where malicious activity is uncovered, much like anti-virus :) I'm not going to get into those.

For the rest of us, we need to trust CAs much less. Not just until the affected CAs move away from MD5, but until the root certs stored in your applications (like your web browser) expire and are changed. This is because the rouge intermediary CA certs will look legit as long as those are. Even then, I don't trust CA's much. I already suggest that in some cases previous to this bug, that certs should be treated like SSH keys. This require evaluating each certificate and trusting it specifically. An easy way to do that beyond having their fingerprints tatoo'ed on your arm is to use the Petnames's add-on for Firefox. The first time you visit a website using SSL that you need to be secure, examine the certificate, if if looks legit, assign it a petname by typing it into the petnames toolbar. Then make sure whenever you visit the site that the petname is displayed. If the petname stops being displayed, try and work out if the previous cert has expired or been legitimately replaced, if not, then it could be a man-in-the-middle attack. A few of the way I recommend checking whether a cert is valid are (in order of usefulness):

1. Check that the URL you're at is the right one. If you want to be a standardbank.co.za make sure there isn't anything else after the za.
2. Make sure all the usual requirements for validity are met. The easiest way to do this is to make sure your browser doesn't pop up any warnings (I'm talking about banks not this site :) ).
3. Check if a user on another computer, using a seperate internet link is presented with the same certificate (double click the lock icon and check the fingerprints).
4. The certificate has been the same for the past couple months/years (this is part of the ongoing observation, rather than the initial).
5. Check that the companies listed in the cert are what are expected, I put this last for a reason.

Apart from (4) this is a once off evaluation that can then be looked after by your petname. It's also something you can install for your non-techie mother and teach her to follow fairly easily: "If this is ever not green or not saying Standard Bank, then phone me."

That's all for now.