quote:

---

14% of SSL Certificates signed using Vulnerable MD5 Algorithm

Netcraft's SSL Survey shows that 14% of valid third party SSL certificates have been issued using MD5 signatures — an algorithm that has recently been demonstrated to be vulnerable to attack by producing a fake certificate authority certificate signed by a widely-trusted third party certificate authority.

The researchers achieved this by producing a hash collision — they submitted valid certificate requests to a certificate authority (CA), while producing a second certificate that had the same signature but entirely different details. When the CA signed the valid certificate, the signature applied also to the invalid certificate, allowing the researchers to spoof any secure website that they liked. This attack is the first practical use against SSL of already-known attacks against the MD5 checksum algorithm.

Netcraft's December 2008 SSL Survey found 135,000 valid third party certificates using MD5 signatures on public web sites, which is around 14% of the total number of valid SSL certificates in use.The great majority consist of certificates from RapidSSL (shown as Equifax on the certiifcate). As of Netcraft's December survey, all of the 128,000 RapidSSL certificates in use on public sites were signed with MD5; there are some much smaller CAs that use MD5 still, and there are a small number of certificates from Thawte and VeriSign, although most of their certificates are signed with the more secure SHA1. Other CAs use only SHA1.

Verisign (owners of RapidSSL since 2006) have stated that they have stopped using MD5-signing for RapidSSL certificates, and will have phased out MD5-signing across all their certificate products by the end of January 2009. Other affected CAs are likely to follow suit, as SHA1 is well established and is already in use for the majority of SSL certificate signing, so it should be simple to switch to using this more secure alternative. Once it is impossible to obtain new certificates signed with MD5, this attack will be neutralised.

The attack requires a collision between newly created certificates — one valid and one fake — deliberately created by the attacker. As such, there is no particular risk to existing SSL certificates signed with MD5, and they do not need to be replaced. VeriSign are nevertheless offering free replacements for customers that want them; and it is possible that browsers will start to distinguish certificates signed with MD5 so that users can exercise caution, as CERT have issued a vulnerability note suggesting that users could check for this manually.

The researchers have noted that certificates for Extended Validation (EV) SSL websites cannot be faked in this way — because the EV standard requires SHA1 or better signatures, and indeed there are no MD5-signed EV certificates found by our survey. This shows that requiring minimum standards from the CAs can have positive effects — hopefully browser vendors will take note, and start requiring that CAs apply similar minimum standards to other certificates.

Security remains a moving target, however, as researchers have also started to find weaknesses in SHA1. Although there are no attacks as advanced as those against MD5, it is likely that SHA1 will also be increasingly threatened by collision attacks as research in this area continues. There are more secure cryptographic hashes available, however, so we can expect to see CAs start to phase in newer, stronger hashes over the next few years.

---

said by nwrickert :

What I don't quite understand about this, is that while signing the certificate the CA makes some editorial changes to the certificate content. These include inserting a serial number and start and expire dates. If these changes are included in what is hashed for the signature, then that would seem to disrupt the method of attack - unless the attacker can predict this data. Maybe serial and date info are not in the signature hash, but that would be a surprising weakness if true.

quote:

---

The relevance of the serialNumber is this: unlike the name and the public key, the serialNumber and validity are generated by the CA. So, you need to know in advance what they will be in order to generate the appropriate colliding "bad" certificate. The validity is typically just generated as something like a year or two from the time of issue, so it's relatively predictable. The CA has a lot of freedom in how to generate the serial number. If it's truly a sequence number, it's quite predictable. However, if it's randomly generated, then it can be made arbitrarily unpredictable, which effectively blocks this kind of collision attack. When MD5 collisions were first discovered, the two standard recommendations were (1) stop using MD5 and (2) generate random serial numbers.

...

Bottom Line
As usual, don't panic. In its current state, this is more of a demonstration of a hole than a serious hole. Countermeasures are readily available to the CAs and if the remaining CAs fix their practices fast enough, then it's unlikely that there will be any more bad certificates issued ...

---