Firefox 32.0 fixes holes, shakes out some old SSL certs, introduces certificate pinning
by Paul Ducklin on September 3, 2014
Yesterday was Firefox’s most recent Fortytwosday(updates come out every 42 days, on Tuesdays, in a nod to Douglas Adams), bringing us to Firefox 32.0.
For those who like to keep their feature set behind the leading edge, yet stay on top of security fixes, there’s also ESR 24.8 and ESR 31.1.
ESR is short for Extended Support Release; these versions are squarely aimed at organisations who need to balance user familiarity with network security, but they’re freely available, just like the mainstream version.
ESR releases have version numbers of the form X.Y, where X is the mainstream major version whose feature set they include, and X+Y is the current major version number of the leading-edge release.
What’s interesting in the ESR security notes for this update is that there are three critical vulnerability reports for ESR 31.1, but only two for ESR 24.8:
That’s because the MFSA 2014-68 advisory doesn’t apply to the codebase that was frozen back at Firefox 24, meaning that the bug was introduced somewhere between versions 25 and 31 inclusive.
This reminds us quite visibly that security really is a journey, not a destination.
Certificate retirement
Another noteworthy point in this Fortytwosday is listed in the general Release Notes, rather than as a security fix:
Removed and turned off trust bit for some 1024-bit root certificates
In cryptographic circles, digital certificates that use 1024-bit RSA keys are no longer considered safe.
That means that it’s no longer wise to trust root certificates that use 1024-bit keys, because a crook who can crack a root certificate key can then sign his own dodgy certificates (of any key length he likes) to give them a bogus imprimatur.
Remember that, for the most part, your browser implicitly trusts any certificate that is signed by a certificate it explicitly trusts.
→ RSA key sizes for public key encryption can’t be compared to AES key sizes for secret key encryption, where 128 bits is currently considered suitable. We explained why last year when Google officially doubled all its RSA key sizes from 1024 to 2048 bits.
By the way, if you’re a user who likes to keep at least half an eye on what certifcates your browser trusts, you’ve probably found the certificate inspection dialogs in Firefox to be very frustrating.
You need to click into each certificate in turn (and there are hundreds of them) to view its details:
If this has ever annoyed you, then you’ll probably find these links useful:
・ Mozilla Included CA Certificate List
・ Mozilla Included CA Certificates (in spreadsheet format)
・ Source code file of Mozilla built-in certificates
・
Perplexingly, Mozilla doesn’t yet seem to have removed all the 1024-bit root certificates in its built-in list of trusted Certificate Authorities.
Presuambly, however, that will happen soon.
Certificate pinning
Another useful new feature introduced in Firefox 32.0 is Public Key Pinning.
Loosely put, certificate pinning works by performing additional checks on HTTPS certificates from popular web properties, instead of checking merely that the certificates are vouched for by a trusted signer.
That’s why we carefully wrote above that your browser “for the most part” implicitly trusts certificates signed by explicitly trusted certificates.
Certificate pinning introduces a sort-of allow list approach by forcing some certificates to meet additional criteria, such as verifying who signed the certificate.
That way, a crook who wanted to create a bogus a Twitter certificate, for instance, couldn’t get his dodgy certificate signed by just anyone: he’d have to subvert the very same certificate authority (CA) that Twitter is known to use.
That’s not foolproof, of course, but it’s generally much harder to pwn a specific CA than to pwn any CA.
Currently, Mozilla is pinning certificates only from itself and Twitter; pinning for Google, Firefox, TOR and Dropbox are promised in the next two releases.
