eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Mozilla will include a new SSL (Secure Sockets Layer)/TLS (Transport Layer Security) certificate checking mechanism in the upcoming Firefox 37 browser release, which is scheduled to become generally available on March 31.
With the new certificate checking technology, called OneCRL (the acronym CRL stands for Certificate Revocation List), Mozilla is pushing a list of revoked certificates into the Firefox browser in an effort to help protect users from bad certificates and potentially malicious Websites. An SSL/TLS certificate is intended to provide both encryption and a measure of authenticity for a given domain.
Today, all modern Web browsers already use the Online Certificate Status Protocol (OCSP) to check with certificate authorities on whether a given site certificate is valid. The new OneCRL effort is not intended to immediately replace OCSP.
“Firefox 37 will continue to support OCSP; it will check both OCSP and OneCRL when evaluating a certificate,” Mark Goodwin, application security engineer at Mozilla, told eWEEK. “As we gain more experience with OneCRL, we will look into disabling OCSP for certificates covered by OneCRL, but we are not taking that step today.”
Goodwin added that there will still be some residual need for OCSP even once OneCRL is fully deployed, since it will not be feasible to cover all end entity certificates with OneCRL. Though OneCRL is not going to fully replace OCSP, Goodwin emphasized that the existing OCSP system is less than ideal. According to Mozilla’s telemetry, OCSP fails more than 1 percent of the time, and even when it works, it takes around 400 milliseconds, he said.
Multiply that by the two to four certificates in a typical chain, and that means that we can’t wait for OCSP without causing significant delays in page loads,” Goodwin said. “OCSP also leaks private information by telling the CA [certificate authority] what sites a user is visiting.”
In contrast, OneCRL lookups are effectively instantaneous, so they cause none of the delays that OCSP requests do, Goodwin claimed. From a privacy perspective, since OneCRL checks are done locally to the browser, neither the CA nor Mozilla finds out where the users are going on the Web.
“OneCRL-based revocation is harder to block because OneCRL updates are bundled in the same channel with other security policies used by Firefox,” he said.
While the typical deployment of OCSP is less than ideal, there is a method known as OCSP stapling that can improve security. OCSP stapling, a technology approach that the Certificate Authority Security Council (CASC) has been pushing for the last two years, allows a Web server to check its status with the CA for Web browser clients, essentially “stapling” the response to the server.
“The drawbacks of live OCSP arise entirely from its being done as a live check between the browser and the CA,” Goodwin said. “By avoiding a second network connection, OCSP stapling addresses the latency, reliability and privacy risks.
Additionally, Goodwin noted that if the certificate also includes a “MUST_STAPLE” extension, there’s no blocking risk. In his view, OCSP stapling addresses pretty much all of the deficiencies of OCSP. Overall, OCSP stapling is also more scalable than OneCRL, he added.
“Obviously, maintaining a database of revocation state for every certificate in the Internet is a Sisyphean task, and OneCRL requires it,” Goodwin said.
Goodwin commented that OneCRL can’t do the whole job when it comes to certificate status checking, and Mozilla’s long-range vision incorporates both OneCRL and OCSP stapling.
“If we can cover most certificates with those two mechanisms, then the vast majority of OCSP checks will be unnecessary,” he said. “That will make the Web both faster and more secure.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.