Benl writes: Improving SSL certificate security

Friday, April 1, 2011 9:05 AM Posted by Ben Laurie, Google Security Team

In the wake of the recent [incident], there has been a great deal of speculation about how to improve the public key infrastructure, on which the security of the Internet rests. Unfortunately, this isn’t a problem that will be fixed overnight. Luckily, however, [engineers] have long known about these issues and have been devising solutions for some time.

Given the current interest it seems like a good time to talk about two projects in which Google is engaged.

The first is the Google Certificate Catalog. Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS. So, for example, if you wanted to see what we think of https://www.google.com/’s certificate, you could do this:

[tech details snipped]

The second initiative to discuss is the DANE Working Group at the IETF. DANE stands for DNS-based Authentication of Named Entities. In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts. So, once more, if a certificate is seen that isn’t consistent with the DANE records, it should be treated with suspicion. Related to the DANE effort is the individually contributed CAA record, which predates the DANE WG and provides similar functionality.

[caveats snipped]

Improving the public key infrastructure of the web is a big task and one that’s going to require the cooperation of many parties to be widely effective. We hope these projects will help point us in the right direction.

If you tried to log in to CATS recently with a newly created certificate you probably failed. Especially when using a Class 3 certificate. Now I hope this bug is finally fixed.

Like usual for such bugs it was quite a trivial thing, for details compare CAcert/Education/CATS/login.php in svn with its previous version.

For analysis: certificates affected contained a serial number wich started with a non-digit character after stripping learing zeros. So Class 3 certificates with serial number bigger than 09:ff (issued since about half a year ago) and Class 1 certificates with serial greater than 09:ff:ff (issued since recently) have been affected.

I’m still waiting for the first explicit confirmation of someone now able to log in, but the analysis nicely fits the symtoms and the problem could be reproduced on the test system, so I hope we finally got it.