Solving The SSL Certificate-Revocation Checking Shortfall

Just weeks after Google turned off revocation checking in Chrome, browser vendors convene at RSA to discuss some solutions to a broken system

RSA CONFERENCE 2012 -- San Francisco, Calif. -- The way that browsers perform SSL certificate-revocation checking is so fundamentally flawed that some browser vendors have turned it off altogether, according to browser vendor representatives in a panel at RSA last week. Moderated by a Certificate Authority (CA) representative, the panel involved key players from Mozilla, Google, and Opera, who all put forward potential solutions to the problem of how to check the valid status of SSL certificates issued by CAs.
At the moment, sites depend on two methods for checking the valid status of SSL certificates online. One is through a certificate revocation list (CRL) published by the CAs, which post revoked certificates periodically on these lists. The other is through the Online Certificate Status Protocol (OCSP) responder systems CAs have in place to relay the up-to-date status of the certificate for a site to a users browser when the user visits the site.
So why are we here today? said panel moderator Kirk Hall, operations director of trust services for Trend Micro. That sounds like a perfect system, right? It should work. But it doesnt.
Hall says there are several reasons why CRLs and OCSP are not working in the real world. For one, the CRLs can be up to seven days old and the CRL in your client at any given time will probably not reflect the most recent list of revocations from that particular root, Hall says.
At the same time, while OCSP is supposed to be a more real-time method of checking, its latency problems have doomed its prospects at the moment. Whether it is through slow responses due to slow connections, connectivity issues involving system firewalls, or scalability issues for CAs responding to OCSP queries at high-volume sites, the number of errors returned by OCSP responders for sites with valid certificates can be quite high. In the name of usability, browser vendors have all but neutered OCSP safeguards by turning off hard-fail when OCSP does not respond with a positive result.
Right now, if your appliance sends out an OCSP query and doesnt get an answer back, you dont know that. Nothing happens; you dont get a warning, Hall says. A lot of times there is nothing wrong with the cert, they just didnt get a response back, so they dont really want to tell you as the consumer that there is something wrong with this site. [The fear is] as soon as one browser does turn on hard fail and consumers start getting failures, there is a fear that consumers will migrate to other browsers that are not that strict.
As a result, most browser vendors currently engage in soft-fail checking, where the browser still queries the OCSP responder for a site, but does nothing if a problem crops up. According to panelist Adam Langley, software engineer for Google Chrome, its a broken system, which is why Google chose to turn off revocation checks a few weeks before the show.
We think thats right for our users. If youre an enterprise and you believe that OCSP does you some utility, you are probably wrong, but there will be a section to turn it on if you want to, Langley said. Right now we are making [users] wait, and were leaking their privacy by doing these soft fail checks. I cant think of any argument that theres any security advantage to do it, so since the cost outweighs the benefit it is not something we should do. Regardless of whether Googles move was right, Langley and his colleagues, Havard Molland, cryptography and network developer from Opera Software, and Sid Stamm, Web security and privacy strategist from Firefox, all agreed the system needs to be fixed and together offered up some possible ways the browser vendors and CAs can work together to come up with a more sustainable method for checking on certification revocations.
For his part, Langley put forth the notion of OCSP stapling, which has the site operator server send its OCSP response along with the certificate, rather than requiring a query of the CA. Already in use in some situations, the difficulty there is that in most cases OCSP responses can be stapled on only one certificate instance, making it difficult to verify certificates with multiple intermediates in the trust chain. Whats more, attackers can currently get around the security of stapling by omitting the staple altogether when using a bogus certificate.
So in order for this to be effective, the clients have to know that this server will do stapling, which is probably going to be an X509 extension that says this certificate must be stapled, Langley says. We dont have that yet. But we could. It just doesnt exist.
Molland brought forward another alternative of using browser-based CRLs, rather than CRLs maintained by CAs.
The proposal is that the browser vendor takes care of that. Then all the CA needs to do is send out the revocation lists to the browser vendor, and the browser will pull [information from its own list], he says, explaining that this solution would allow for the browser to easily revoke a certificate itself in high-profile situations, such as the ones that hit Comodo and DigiNotar last year. We could revoke the whole certificate without releasing a new version of the browser. And Stamm introduced the proposal of short-term certificates, whose short life span would ensure validity in a shorter window than most OCSP responses.
One of the pros of this is that you dont really need to rely on browsers to block list certs when key information is compromised because theyre short-lived and the window of exposure is essentially the same as an OCSP response that could be relayed, Stamm says. We currently have the infrastructure for validating certs. We could just throw out the need for extra revocation and rely on the lifetime of the cert so we dont have to do this revocation checking on top of the cert validation.
However, the big downside to this plan is it would require key rotation and more infrastructure from site operators.
According to Hall, the issue of revocation is high on the list of member organizations within the CA-Browser Forum (CAB Forum). He told the audience to stay tuned as the forum addresses proposals such as OCSP stapling in the coming months, trying to make fast progress where at all possible.
There are new CAB Forum initiatives coming up, Hall said. The forum is going to look at what it can do today to try to make revocation checking better.
Have a comment on this story? Please click Add Your Comment below. If youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Solving The SSL Certificate-Revocation Checking Shortfall