Risk

10/28/2015
06:00 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Digital Certificate Security Fail

Eight percent of digital certificates served by websites had been revoked but are still in use, new study finds.

The use of digital certificates to authenticate websites and encrypt online communications is not as secure as generally assumed, a new study has found.

Researchers at Stanford University, Northeastern University, University of Maryland, Duke University, and Akamai Technologies recently evaluated the Web’s certificate revocation processes and discovered that certificate authorities, website administrators, and Internet browser makers are falling down on the job.

The study, presented this week at the Association for Computing Machinery Internet Measurement Conference in Tokyo, found that a disturbingly large 8 percent of public key certificates served by websites have been previously revoked. Certificate Authorities, the entities that distribute digital certificates, use non-optimal processes for distributing revocation lists while many browsers routinely fail to check whether a certificate has been revoked or not, the researchers said.

The findings are troublesome because users trust the security precautions in their browsers and on the websites study co-author Dave Levin, an assistant research scientist at the University of Maryland, said in a statement.

The results highlight the need for all participants in the revocation ecosystem to step up their game and fulfill their responsibilities, he said.

Digital certificates are a vital component of the Web’s public key infrastructure. They are used to authenticate websites and to encrypt communications between a client system and a server. If a website is compromised or the private encryption key associated with a digital certificate is exposed, the certificate is supposed to be revoked so others cannot use it to impersonate the site or to snoop in on it.

Typically, the website administrator is required to ask his or her certificate authority to revoke the compromised certificate and to then reissue a new one. The researchers found that a surprisingly large number of websites continue to serve up certificates long after they have been revoked. This suggests that Web administrators who go through the effort of getting a certificate revoked then often fail to update all of their systems with the new certificate.

A revoked certificate shouldn't typically present a security problem because browsers are supposed to check whether a certificate is valid before accepting it. Certificate Authorities distribute what are known as certificate revocation lists (CRLs) that browsers are supposed to check before trusting or rejecting a certificate.

The study titled, “An End-to-End Measurement of Certificate Revocation in the Web’s PKI,” uncovered several troubling weaknesses in the manner in which desktop browsers used revocation lists. According to the researchers, no browser in its default configuration checked all revocations or rejected certificates if current revocation information was not available. The situation is even worse with mobile browsers. Not one of the major mobile browsers checked to see if a certificate was valid or had been revoked.

One reason could be the size of the CRLs maintained by the different certificate authorities.  “Properly verifying a certificate requires the client to download the CRL before fully establishing the SSL connection,” the report said. But because the CRLs are often relatively large, downloading them could introduce latency issues especially in the case of bandwidth constrained mobile environments.

Meanwhile, many certificate authorities are not doing a particularly efficient job in ensuring proper distribution of CRLs, the researchers said. Some certificate authorities have begun using multiple CRLs to keep their lists small but many continue to use large bulky CRLs that browsers tend to ignore.

In order for certificate revocation to work in the manner intended, Web administrators, certificate authorities, and browser makers need to meet their responsibilities, the researchers said. “If administrators fail to request revocations, CAs fail to distribute them, or browsers fail to fetch them—users risk being susceptible to impersonation attacks.”

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
UmeshKTiwari
50%
50%
UmeshKTiwari,
User Rank: Strategist
10/29/2015 | 12:28:13 PM
Digital Certificate Security Fail
The answer is very simple. Start treating certificates with some respect and not manage them with stone age approach. Automate certificate management and keep track of all of your cert stores. 
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Well, at least it isn't Mobby Dick!
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-9923
PUBLISHED: 2019-03-22
pax_decode_header in sparse.c in GNU Tar before 1.32 had a NULL pointer dereference when parsing certain archives that have malformed extended headers.
CVE-2019-9924
PUBLISHED: 2019-03-22
rbash in Bash before 4.4-beta2 did not prevent the shell user from modifying BASH_CMDS, thus allowing the user to execute any command with the permissions of the shell.
CVE-2019-9925
PUBLISHED: 2019-03-22
S-CMS PHP v1.0 has XSS in 4.edu.php via the S_id parameter.
CVE-2019-9927
PUBLISHED: 2019-03-22
Caret before 2019-02-22 allows Remote Code Execution.
CVE-2019-9936
PUBLISHED: 2019-03-22
In SQLite 3.27.2, running fts5 prefix queries inside a transaction could trigger a heap-based buffer over-read in fts5HashEntrySort in sqlite3.c, which may lead to an information leak. This is related to ext/fts5/fts5_hash.c.