OneCRL: Firefox 37 to check security certificates via blocklist
Thu 5 Mar 2015
The next version of Firefox will include a ‘pushed’ blocklist of revoked intermediate security certificates, in an effort to avoid using Online Certificate Status Protocol (OCSP) checks to ascertain the continuing validity of a security certificate.
Under the new OneCRL system the list of revoked intermediate certificates (RICs) will reside locally to the end-user in the same manner as other blacklists (or, indeed, whitelists) used by plug-ins such as ad-blocking software, which download updates regularly into the local user set-up.
The OneCRL list is a outgrowth from Firefox’s existing blocklisting procedure, which covers malfeasant add-ons, plug-ins or faulty graphics drivers, and the post at the Firefox blog cites the main advantage of including RICs as one pertaining to speed:
“For certificates covered by OneCRL, there is no need to do live OCSP checks, so revocation checking incurs no additional latency. The is especially important for EV certificates, where a positive OCSP response is required.”
EV (Extended Validation Certificate) certificates are X.509 public key certificates which require a positive OCSP response. The latency issue can already be addressed by OCSP stapling, which permits non-live verification, but is currently only used in 9% of TLS certificates.
A web-browser which cannot get a ‘live’ response via an OCSP request has the option either to ‘soft-fail’ – wherein it accepts a potentially compromised certificate – or ‘hard-fail’ – wherein it rejects the connection, even though the certificate may be valid and the certificating authority currently besieged by a DDoS attack or temporarily unavailable for legitimate reasons. Blocklisting permits connections to be made under such circumstances based on recent – but not live – information.
The Google Chrome browser has been implementing its own pushed blocklist for nearly three years, called CRLSet. As Google software engineer and Chrome developer Adam Langley observed last year, “online revocation checking is useless – because it doesn’t stop attacks. Turning it on does nothing but slow things down. You can tell when something is security theater because you need some absurdly specific situation in order for it to be useful,”
Both Firefox’s new OneCRL feature and Chrome’s CRLSet have limitations – currently the Firefox blocklist will only cover intermediate certificates, due to initial size-limits on the blocklist, whilst the Chromium blog specifically mentions that CRLSets’ size-limit tops out at 250kb. Both datasets rely on the developers trawling CAs daily for new additions and amendments, and pushing the updated list to the browser. The Chrome certificate updates are pushed “at most once every few hours”, whilst the Firefox implementation does not specify a frequency period.
Certificates are issued for periods of several years, and the issue of ‘legacy’ certificates has jumped sharply into focus in the last 24 hours, due to exposure for the FREAK (Factoring Attack on RSA-EXPORT Keys/CVE-2015-0204) vulnerability, in which ‘export-grade’ or ‘weekend’ 512-bit security keys were required for non-US sites by the NSA, since these weaker certificates were easier for the security agency to intercept and monitor. FREAK exploited a method whereby a browser could be forced to ‘downgrade’ from the higher-security certificates which succeeded the ‘export grade’ ones from the 1990s, and use the legacy certs, which one researcher succeeded in cracking within seven hours using Amazon computing services. Ironically the NSA’s own website turned out to be vulnerable to FREAK exploits.
