Mozilla plans to more strictly enforce industry best practices for SSL certificates in future versions of Firefox with a new certificate verification system.
The new system will be implemented as a library called “mozilla::pkix” and will start being used by Firefox 31, which is expected to be released in July.
Many of the certificate verification changes in the new library are subtle and are related to technical requirements specified in the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” issued by the Certification Authority/Browser (CAB) Forum. However, some of the behavior modifications also stem from changes Mozilla made to its own policy for trusting CA certificates.
For example, a document describing mozilla::pkix requirements notes that “end certificates used by servers are not allowed to have basic constraints asserting isCA=TRUE” and “certificates used as trust anchors or intermediates are now required to have the basic constraints extension and assert the isCA bit.”
Fighting bad certificates
These two requirements are intended to prevent the misuse of subordinate CA (sub-CA) or intermediate certificates, which can be used to issue SSL certificates for any domain on the Internet.
In February 2012, Trustwave, one of the CAs trusted by browsers, publicly admitted that it had issued a sub-CA certificate for use by a third-party company to inspect SSL traffic passing through its corporate network. Mozilla said at the time that the use of sub-CA certificates for man-in-the-middle SSL traffic monitoring, even if performed on closed corporate networks, is unacceptable.
Another incident happened in January 2013, when a certificate with sub-CA status issued by Turktrust, a Turkish certificate authority trusted by browsers, was installed in a firewall appliance with SSL traffic monitoring capabilities by the Municipality of Ankara. Turktrust said the certificate in question was one of two that had been issued with sub-CA status by mistake in August 2011 and were actually supposed to be regular end-user certificates.
A month later Mozilla changed its CA policy to require all sub-CA certificates to be technically constrained to particular domain names using certificate extensions or to be publicly disclosed and audited as regular root CA certificates. The mozilla::pkix certificate verification library will begin enforcing that policy change inside the browser.
While the majority of Firefox users are unlikely to notice anything out of the ordinary as a result of the new certificate verification system, some HTTPS websites might encounter problems.
“While we have performed extensive compatibility testing, it is possible that your website certificate will no longer validate with Firefox 31,” the Mozilla Security Engineering Team said Thursday in a blog post. “This should not be a problem if you use a certificate issued by one of the CAs in Mozilla’s CA Program, because they should already be issuing certificates according to Mozilla’s CA Certificate Policy and the BRs [the CAB Baseline Requirements].”
Mozilla also created a special bug bounty program that will pay out $10,000 for any critical security flaw found and reported in the new library’s code until the end of June.
“As we’ve all been painfully reminded recently (Heartbleed, #gotofail) correct code in TLS libraries is crucial in today’s Internet and we want to make sure this code is rock solid before it ships to millions of Firefox users,” Mozilla’s security lead Daniel Veditz said Thursday in a blog post.
“We are primarily interested in bugs that allow the construction of certificate chains that are accepted as valid when they should be rejected, and bugs in the new code that lead to exploitable memory corruption,” Veditz said. “Compatibility issues that cause Firefox to be unable to verify otherwise valid certificates will generally not be considered a security bug, but a bug that caused Firefox to accept forged signed OCSP [Online Certificate Status Protocol] responses would be.”