A few days ago, a group of scientists and security specialists finally succeeded to create a rogue CA that was able to issue certificates that are accepted by all browsers:
http://www.win.tue.nl/hashclash/rogue-ca/ and http://www.phreedom.org/research/rogue-ca/ The problem underneath are weaknesses that were discovered in the MD5 hash-algorithm.
CAcert has switched from MD5 to SHA-1 for certificate-issueing a few years ago, when the first research results were made public that indicated that such an attack will become feasible. CAcert is currently still using an intermediate CA that was issued with an MD5 based signature 3 years ago. We are currently working to phase out this intermediate CA.
We suggest that all certificates (except for root certificates, which aren’t affected), regardless of which CA has issued them, that were still issued with MD5, be replaced with SHA-1 based certificates within the next 3 months. We also suggest that all company-internal or organisation internal CA’s be checked and switched from MD5 to SHA-1 where necessary. To detect, whether a webserver certificate or any of the intermediate certificates are MD5 based, you can use this Firefox extension: http://codefromthe70s.org/sslblacklist.aspx
Happy new year!
Just FYI, the level-3 root of CaCert is signed using MD5.
If I understood correctly, the purpose of such a level-3 certificate is to be used as a chained certificate so that browsers only need to install level-1, and the webserver can supply the level-3 as a “missing link”. However, such usage will no longer work with the SSL Blacklist. Of course, the warning will stop if the level-3 certificate is directly installed in the browser, but is that how it is intended to be used?
Shouldn’t it be re-signed as SHA-1?
Yes, the Class-3 certificate is an intermediate certificate. Yes, unfortunately the SSL Blacklist can’t differentiate between old MD5 certificates that are not vulnerable and new MD5 certificates that are vulnerable, so it classifies our class3 certificate as potentially rogue.
I am not sure, whether installing it in the browser actually helps or not, it might help though. And no, the intention was to have it installed on the webserver.
Re-Signing a certificate with a different Hash algorithm doesn’t work, since it would create a different certificate (due to the different hash), that still has the same serial number, and that is forbidden. (And a few applications invalidate the whole CA tree as soon as they see a single occurance of a serial number in different certificate). So we would have to issue a different class3 intermediate certificate.
GnuTLS already rejects MD5 certs by default for some time now, even before the successful attack became known. I really hope to see a new class3 cert soon.
I’m asking if it’s really wise to promote SHA-1 as a solution. From what I know, CAcert anyway plans to create a new root cert soon, though I don’t know how feasible SHA-256 certificates are these days.
Though it’s known that similar weaknesses like the ones in MD5 are also in SHA-1, with much larger computation power needed to do the attacks, but still, not really out of scope.
Yes, SHA-1 isn’t a complete solution, but it’s better than MD5, and it’s available.
SHA-2 might be available enough now that we can try it. I doubt that it is widely available enough that a large user group could work with it yet.
Please see http://wiki.cacert.org/wiki/SecurityNotes for more details on the issue of MD5, SHA-1, and SHA-2.
There is CAcert internal discussion if it is worthwhile to create a new class 3 intermediate certificate or wait till the new generated Root Keys from November 2008 are effectuated. The new Root Keys are becoming only available for the CAcert Community Members (the new regime: signed CCA and Assurers who passed the Assurer Challenge).