SSL

Late last month, we were advised that some malware used in a spear-phishing attack was signed using 512-bit RSA Web server certificates. In a recent blog post from FOX-IT, it was confirmed that the abused certificates were issued by more than one CA to more than one subscriber and it was concluded that the certificate keys had not been stolen, but had been derived from the public keys. That is, the public key was so small that a hacker could, via brute-force attack, guess the private key.

This is not how public key cryptography is supposed to work. The keys should be sufficiently large that the amount of resources and time required to derive the private key would be too large and too long to make the effort worth it. What happened?

Two things. First, some Web server administrators are still generating weak key pairs. Unfortunately, these admins are not aware of best practices with regards to key sizes for SSL certificates. In 2011, 1024-bit RSA is still allowed, but 2048-bit RSA is recommended; 512-bit RSA is definitely a no-no. The second issue is that some CAs were not checking and enforcing minimum key size requirements.

So how can a Web server certificate be used to sign malware? Don’t you need a code signing certificate to sign code? This is another problem. The way the certificate purpose is assigned is through an extension in the certificate called Extended Key Usage (EKU). There are EKUs for SSL, code signing, and S/MIME, amongst others. The certificates used in the spear-phishing attack had no EKU extension. No EKU doesn’t mean “no purpose.” It means “ALL PURPOSES.” So these so-called Web server certificates could be used to sign code. This is not caused due to a Web server admin’s error; this is caused by the CAs not restricting the usage of their certificates with an EKU.

Entrust got involved because we cross-signed a CA in Malaysia that was issuing SSL certificates with 512-it keys and no EKUs. The result was that Entrust revoked the cross-certificate and the cross-certificate was blacklisted by the browsers [1][2][3].

So, if there were other CAs that issued SSL certificates with weak 512-bit keys and no EKUs, why was the Malaysian CA singled out and blacklisted by the browsers? The fact is, Digicert Malaysia committed a trifecta of certificate issuance faux pas — weak keys, no EKU, and no revocation information. All of the other CAs were able to revoke their certificates, so the certificates would no longer be trusted.

Digicert Malaysia failed to put information in their certificates that would allow the end-user to determine whether or not their certificates were still trustworthy. This left revocation and blacklisting of their CA certificate as the only reasonable recourse.

So what can we take away from this situation?

• The SSL industry needs a common standard for all CAs to follow when issuing certificates. This standard needs to include recommendations for key size and certificate profiles. More to follow on a future post.
• Web server administrators need make sure that they are creating keys that are at least 1024-bit RSA and preferably 2048-bit RSA.
• Public CAs will correct their issuing practices, but enterprise CA operators should ensure that their CAs are configured properly as well.
• Browsers should consider building in safeguards, so that non-complaint certificates are not given the same user interface treatment as compliant certificates.

A final thought. Mistakes happen, which are expected when issuing SSL certificates. That is why the system is designed to be resilient and mitigate various security incidents. In this case, the browsers and the effected CAs worked together to resolve the issue and restore a secure state in a swift manner.