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 a site's certificate to a user's browser when the user visits the site.
[ Catch up on our complete RSA 2012 Security Conference coverage. ]
"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.
Secure sockets layer isn't perfect, but there are ways to optimize it. The new Web Encryption That Works supplement from Dark Reading shows four places to start. (Free registration required.)