I've read that various Web browsers handle SSL certificate revocation differently. Can you explain how the major...
browsers handle this important security task? Should the revocation method play a role in selecting a browser for users?
Digital certificates are used to provide a key with which to encrypt the conversation between browsers and websites that communicate using the Transport Layer Security or Secure Sockets Layer protocol. They also provide third-party verification -- via a certificate authority (CA) -- of the certificate owner's identity. The level of verification varies from simple confirmation of control of the domain name -- Domain Validation -- to more extensive identity checks -- Extended Validation (EV). There is often a chain of certificates from the Web server's certificate to the CA's trusted root certificate installed in the browser or operating system, each one validating the certificate below it.
As you might expect, certificates expire and occasionally need to be revoked. Revocation occurs when the certificate owner no longer controls the domain for which it was issued, a certificate is mistakenly or fraudulently signed, or a certificate's private key is compromised. The ability to revoke such certificates is critical. An attacker with access to an unrevoked certificate and its private key can perform a man-in-the-middle, or MitM, attack by presenting the certificate to unsuspecting users whose browsers believe they are connecting to a legitimate site.
There are two main technologies browsers can use to check the revocation status of a particular certificate. Online Certificate Status Protocol (OCSP) provides real-time revocation information about an individual certificate from an issuing CA. A Certificate Revocation List (CRL) is a list of certificates revoked by a CA that is cached by the browser so it doesn't need to be repeatedly downloaded.
The use of these two forms of revocation checks varies among browsers and in some instances, even which OS the browser is running on. Worryingly, some browsers do not cover all possible certificate scenarios, as shown by the recent situation with an intermediate certificate issued to Network Associates. It was used to sign multiple McAfee SSL certificates (including the one for McAfee's official store), but was revoked on April 30, 2013. Anybody visiting one of the sites signed by the revoked certificate after this date should have received a warning from their browser that the certificate could not be trusted. Unfortunately, in many instances this didn't happen.
Ask the Expert
SearchSecurity expert Michael Cobb is standing by to answer your questions. Submit them now via email. (All questions are anonymous.)
Mozilla Firefox does not automatically download CRLs for non-EV certificates, so the browser relies on OCSP to check if a certificate has been revoked. However, the certificates issued to Network Associates did not provide an OCSP server URL, so CRL was the only option. A CRL can be cached for some time, which can lead to users not receiving the appropriate invalid certificate warnings from their browser. If a user visited any of the other 14 websites with the same intermediate certificate, they would have had a cached version of the out-of-date CRL list.
Furthermore, it seems that for non-EV certificates, Firefox checks the validity only of a server's certificate, not the entire chain of certificates. Apple Safari and Google Chrome behave in a similar way, though Chrome does provide the option to enable proper revocation checks. Both Internet Explorer and Opera do a far more thorough job; they both support OCSP and CRL, and perform suitable checks for all types of certificates. In my opinion, IE and Opera currently appear to handle revocation better than other browsers.
However, it's not just browsers that are undermining the revocation process. RSA Security, which signed and later revoked the Network Associates certificate, doesn't deliver its CRLs in the conventional binary format. Rather, it encodes them into a text-based format. Firefox and Chrome on Linux do not support this format. The inconsistent provision of revocation information by CAs and the variable methods browsers use to check it need to be rectified before users start to lose trust in HTTPS for online transactions.
Dig Deeper on Web browser security
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading