Browsers may need to revamp the SSL revocation process
One area where web browsers and SSL certifiactes need to improve is the certificate revocation checking process, according to a panel at the RSA Conference 2012. Ericka Chickowski of Dark Reading said the system is so fundamentally flawed that many browser operators have turned it off altogether, but there are potential solutions to make it easier on businesses and people surfing the web.
Right now, the process works on two methods of checking SSL certificates; in one, the revocation list is checked by the certificate authority, which posts revoked certificates on that list intermittently. The other method has online certificate status protocol responder systems, which keep the website's certificate up to date when a user visits a website.
"So why are we here today?" said panel moderator Kirk Hall, operations director of trust services for Trend Micro, according to the Dark Reading story. "That sounds like a perfect system, right? It should work. But it doesn't."
According to Hall, there are a few reasons why this isn't working in real life, including the CRL approach probably not reflecting the most recent list at all time, while the OCSP approach has connectivity issues, scalability issues or a high volume of queries slowing things down.
"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," Chickowski said.
A story last year on eSecurity Planet said Mozilla Firefox was having problems with the DigiNotar SSL certificate authority, which led to breaches. The browser tried removing the root of the problem but was still at risk. Companies and browsers may have to figure out a way to work better together so these SSL certificates and companies are not put at risk as much as they could be. It is currently up to companies to make sure they are doing enough on their end to keep the website and customers as safe as they possibly can.