When you tell people that revocation doesn’t work, they tend to look at you incredulously: “You’ve got all these solutions: full CRLs, CRL distribution points, delta-CRLs, indirect CRLs, OCSP, stapled OCSP. Surely one of those will work.”
That’s the problem, right there. There are so many protocol and configuration choices that no two products or services have chosen compatible options. Result? Revocation doesn’t work for the Web. If browser suppliers discover a mis-issued certificate, instead of asking the CA to revoke it, they issue a software update that blacklists the certificate. While it’s widely acknowledged that this is not a sustainable solution, there is no agreement yet on what IS a sustainable solution.
The industry intends to move to “hard fail.” That means that CAs can offer their customers the option that browsers will fail to display their site if the browser cannot obtain confirmation that the certificate remains valid. Maybe, in some distant future, browsers will always behave that way, whether the customer chooses or not.
You’ll quickly recognize that this behavior makes the CA’s revocation service critical to the operation of the website, so it becomes an attractive point of attack for DDOS against the customer’s operations. And, if it’s going to offer this service, the CA must play close attention to safeguard against these types of attack.
Stapling of OCSP responses is likely going to be a part of the “hard fail” solution. A site that uses OCSP-stapling pre-fetches the OCSP response for its certificate and delivers it to the user’s browser during the TLS handshake. This approach offers a privacy advantage. But, the main benefit is the browser doesn’t have to make a separate connection to the CA’s revocation service before it can display the Web page. This gives better performance and reliability.
Except in the hard-fail case, OCSP-stapling offers little security benefit over simply ignoring revocation status, because it’s a simple matter for an adversary in the vicinity of the user to block a stapled response and cause the browser to display the page, even though the certificate has been revoked. But, if the certificate could indicate that a stapled response should be present, and the page should only be displayed if it is, then stapled OCSP offers a good defense against a private-key stolen from the site operator.
So, what’s the summary? At some point in the future, revocation will be completely effective against attacks, including mis-issuance stolen private keys. But, that situation is some way off. In the foreseeable future, however, revocation will become effective against theft of a site operator’s private-key. And, certificate customers will be able to choose this service when they apply for a certificate. Even this improvement depends upon some updates to the certificate standard, and some hardening of operational revocation systems.
Another project that the industry needs to undertake is to ruthlessly profile revocation protocols, and lobby browser suppliers, Web-server suppliers and operators, and CAs to support the agreed profile. Choice is a fine thing. But, here’s a case in which too much choice has led to misalignment among the various parties involved, resulting in an overall system that is dysfunctional.
Having said that, the industry is now stepping up to correct the situation. And we can see how revocation is destined to become an effective safeguard against some important attack vectors.