Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint //

Authentication

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
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15930
PUBLISHED: 2020-09-24
An XSS issue in Joplin desktop 1.0.190 to 1.0.245 allows arbitrary code execution via a malicious HTML embed tag.
CVE-2020-19447
PUBLISHED: 2020-09-24
SQL injection exists in the jdownloads 3.2.63 component for Joomla! com_jdownloads/models/send.php via the f_marked_files_id parameter.
CVE-2020-3560
PUBLISHED: 2020-09-24
A vulnerability in Cisco Aironet Access Points (APs) could allow an unauthenticated, remote attacker to cause a denial of service (DoS) on an affected device. The vulnerability is due to improper resource management while processing specific packets. An attacker could exploit this vulnerability by s...
CVE-2020-3509
PUBLISHED: 2020-09-24
A vulnerability in the DHCP message handler of Cisco IOS XE Software for Cisco cBR-8 Converged Broadband Routers could allow an unauthenticated, remote attacker to cause the supervisor to crash, which could result in a denial of service (DoS) condition. The vulnerability is due to insufficient error...
CVE-2020-3510
PUBLISHED: 2020-09-24
A vulnerability in the Umbrella Connector component of Cisco IOS XE Software for Cisco Catalyst 9200 Series Switches could allow an unauthenticated, remote attacker to trigger a reload, resulting in a denial of service condition on an affected device. The vulnerability is due to insufficient error h...