Endpoint // Authentication
3/5/2012
08:25 AM
Connect Directly
RSS
E-Mail
50%
50%

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

Click here for more articles.

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 user's 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 doesn't."

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 doesn't get an answer back, you don't know that. Nothing happens; you don't get a warning," Hall says. "A lot of times there is nothing wrong with the cert, they just didn't get a response back, so they don't 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, it's a broken system, which is why Google chose to turn off revocation checks a few weeks before the show.

"We think that's right for our users. If you're 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 we're leaking their privacy by doing these soft fail checks. I can't think of any argument that there's any security advantage to do it, so since the cost outweighs the benefit it is not something we should do." Regardless of whether Google's 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. What's 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 don't have that yet. But we could. It just doesn't 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 don't really need to rely on browsers to block list certs when key information is compromised because they're 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 don't 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 you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-0334
Published: 2014-10-31
Bundler before 1.7, when multiple top-level source lines are used, allows remote attackers to install arbitrary gems by creating a gem with the same name as another gem in a different source.

CVE-2014-2334
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2335
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2336
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 and FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2334 and CVE-2014-2335.

CVE-2014-3366
Published: 2014-10-31
SQL injection vulnerability in the administrative web interface in Cisco Unified Communications Manager allows remote authenticated users to execute arbitrary SQL commands via a crafted response, aka Bug ID CSCup88089.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.