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.”