Certificate revocation controversy heats up

In the aftermath of the Heartbleed bug, everyone finally got tired of pointing fingers at OpenSSL, it being too easy to do so. The new finger-pointing game is between supporters and opponents of Google's CRLSet scheme for revocation checking.

I took Google's side on this last week, but others disagree, including Steve Gibson, a well-known developer. Gibson's argument is basically a criticism of CRLSets, but also defends the existing system.

Google's Adam Langley, who has been vocal on the subject, addressed the criticism in his blog. Langley has for years been at the forefront of making the web more secure. He is one of those who got Gmail and other important Google services all-SSL, pressuring other vendors to do the same. We're lucky that Langley is working for an important vendor like Google.

Most criticisms of CRLSets basically come down to the fact that they don't include most revoked certificates. Google has tried to get CAs to cooperate in growing the CRLSets but it seems they haven't been cooperative. In his blog, Langley explains the very reasonable requests Google made.

And in fact, Langley goes on to show that CRLSets, as they currently work, aren't sustainable in the long term anyway. They just get too big because there are too many revoked certs.

But the alternatives are clearly broken. He explains, for instance, the role of a Microsoft library called CAPI (Cryptographic Application Programming Interface), which handles certificate revocation for Windows programs such as Internet Explorer and Chrome. When it has 50 or more OCSP responses for a given CA certificate it will download the CRL. CAs know this and split their CRLs into smaller files so that they don't have to serve large CRLs all the time. This makes a mockery of the claimed cache benefits of CRLs.

Incidentally, Firefox does not use CAPI, partly because they write their own crypto libraries and partly because they don't even support CRLs. They do OCSP on everything.

After my last article praising CRLSets I was approached by the CA Security Council, a CA industry group. They made some of the same arguments that Gibson makes about CRLSets, but they didn't try very hard to defend the current regime.

I did ask them about what could work in the long term, and we agreed that a combination of a new standard called OCSP Must Staple and hard failing would be effective, particularly in combination with short OCSP validity periods. What does all that mean?

OCSP Stapling allows the presenter of a certificate (e.g., https://www.amazon.com) to include an OCSP response with the certificate that they present to clients. This is a major convenience and performance boost for clients (the ones that actually check revocation), but it's just an option.

OCSP Must Staple is a policy that says that the certificate presenter must include a stapled response or the client may refuse connection.

Combine Must Staple with hard fail in cases where a response is not provided or where it indicates revocation, and make the OCSP validity period sufficiently short (preferably hours) and you'd have a pretty robust system that would protect clients against revoked certs (except perhaps shortly after the revocation).

Unfortunately, the CA infrastructure is nowhere near ready for such a system. It would require very high levels of availability or suddenly lots of clients would be experiencing lots of hard failures. The fact that they were happy with soft fails before all this shows how seriously they take the problem.

Recently, discussing the Triple Handshake bug in TLS, I pointed out that major standards shifts for security reasons can only succeed when there's a big, powerful actor involved in a position to force the players forward. Based on the response to CRLSets, it seems (incredibly) like Google isn't big and powerful enough.

But Microsoft is.

All programs that use the Windows Crypto API check against the list of trusted certificate authorities maintained by Microsoft for Windows. Being kicked out of that list would be death for a CA. Microsoft doesn't throw this weight around very often, but they do at times. For instance, as of January 1, 2016 they will no longer allow CAs in the program to issue certificates using SHA-1 as a hashing algorithm.

(Incidentally, you'd think with all the revoking and reissuing going on, now would be the time to start using SHA-2. I've looked and seen no evidence of it.)

If Microsoft were to get on board for a system to improve revocation and put the weight of their Root Certificate program behind it, you can bet it would get done.