RapidSSL CA - MD5 and detailed info about the problem(see 25C3 Talk)

Details about how MD5 weaknesses especially what is refered to as known prefix collisions were used to help to compromise the trust put into one of the CA's that is builtin major browsers :
http://www.win.tue.nl/hashclash/rogue-ca/

Quick Summary:
Not all CAs using MD5 are automaticaly broken, three things were required :
- MD5 signed CA
- prediction of the Serial Number (RapidSSL increments by one)
- prediction of the certificate validity date (RapidSSL issues always 6 second after your press the button.
- A way to find collisions fast enough

Only with these 4 things in place it was possible to pull this off.

More information :

History:
2004 - first attacks against md5
2006 - Colliding PKCS Certificates http://www.win.tue.nl/~bdeweger/CollidingCertificates/
2007 - know prefix collision attacks against md5 futher speeding up the time it takes to find collisions.

Basicaly the stage for the attack shown this year at 25c3 attack was already set in 2006 however the Serial number + Validity period were a problem, because you don't know where they are (in the data) in advance.

So how to reduce the entropy (uncertainty what the validty of the certficate is) ? They found a way to use the RAPIDSSL autonomous system which gives the certificate extactly 6 seconds after you click the I approve button.

What about the Serial number? How to predict the serial number ? RapidSSL just incremented the serial number by one...

This means they potentialy could predict the serial number,however they need three days to bruteforce the collisions - so they needed to get the serial number right for that date - they choose sunday night because the entropy introduced by customer buying certificates hindered the process of hitting the sweet spot.

The required 4 attempts, the three previous times someone else got the Serial Number they targeted.

The question what happens with certificates that use MD5 checksums have been
openly asked (and tried to be answered) in 2005 as shown here :
http://www.cryptography.com/cnews/hash.html

Summary :
Academic research + hacker ingeniousty at it's finest. We need more of it. Awesome.
This only worked because RapidSSL incremented the serial number by 1 and they could predict the validity date.

So, in other words : Remove (or edit the Trustsettings) for the following CA's -

Firefox :
* 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


(Thanks to Security4all)