CCC Create a Rogue CA Certificate

t3rmin4t0r writes "Just when you were breathing easy about Kaminsky, DNS and the word hijacking, by repeating the word SSL in your head, the hackers at CCC were busy at work making a hash of SSL certificate security. Here's the scoop on how they set up their own rogue CA, by (from what I can figure) reversing the hash and engineering a collision up in MD5 space. Until now, MD5 collisions have been ignored because nobody would put in that much effort to create a useful dummy file, but a CA certificate for phishing seems juicy enough to be fodder for the botnets now."

Comments

Alright this Internet is ruined

[Anonymous Coward]

Let's go make a new one.

Rouge CA?

[realmolo]

I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.

It's ROGUE you dumbass.

Re:Rouge CA?

[nsushkin]

I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.

It's ROGUE you dumbass.

Surely you meant FUCHSIA

Why trust the PKI?

[characterZer0]

Why does your bank not give you a compact disc with their public key on it when you sign up for an account?

CA's using MD5

[xaosflux]

FTA, the following common CA's are still using MD5.

RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1

FreeSSL (free trial certificates offered by RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications

TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de

RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority

Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com

verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

A nice piece of work

[Animats]

That's a nice piece of work. I'm very impressed.

Practical conclusions:

• The weakest trusted CA in the world compromises the entire public key infrastructure. What they've been able to do is not just create a phony SSL cert. They've been able to create a trusted but phony certificate authority root certificate which can be used to sign other certificates.
• MD5 has to go. The PKI infrastructure already supports SHA-2, which is considered better; MD5 is only there for legacy certs. So an upgrade doesn't require end-user browser changes; it can all be done by CAs and web sites.
• It's not that hard to do this attack, but it does take some resources. They used a farm of 200 Playstation 2 machines to attack MD5. This is well within the capabilities of, say, the Russian Business Network.
• RapidSSL and FreeSSL seem to be the current weakest points in the system. "Out of the 30,000 certificates we collected, about 9,000 were signed using MD5, and 97% of those were issued by RapidSSL." Worse, those two issuers issue certs with ascending non-random serial numbers, so that, with careful timing, they can be induced to issue a cert with a known bit pattern, which is required for this attack. Probably, RapidSSL and FreeSSL's trusted root cert should be pulled from IE and Netscape, and all certs from those sources re-issued using SHA-2 hashes.
• I don't think the RapidSSL and FreeSSL root certs are EV-enabled, so this specific attack probably can't be used to generate phony Extended Validation certs. Also, the EV standards require SHA-2 or better hashing, not MD5, which is more of a legacy hash algorithm. So the EV cert world is probably still secure.

collision attacks are easy to identify

[conspirator57]

note that the collision attack requires a bit of junk in the cert to make the hash be the same as for the original... this means the junk will not look like the rest of the cert. the rest of the cert is formatted and the collision noise will look mostly random. a simple test for unexpected randomness in the cert data (including Netscape comments) would reveal this sort of mischief. it just takes a bit of code on the browser to look for it. shouldn't even degrade browsing performance too much.