CA/Revocation Checking in Firefox
Contents
Revocation Is Important
Support for revoking certificates is important, because otherwise stolen and misissued certificates can be misused until they expire. History, from DigiNotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Mozilla has and will continue to invest in certificate revocation checking.
Recent changes to the CA/Browser Forum Baseline Requirements (BRs) and Mozilla’s Root Store Policy have reduced the risks associated with exposure of the private key for each TLS certificate:
- Subscriber Certificates issued on or after 1 September 2020 … MUST NOT have a Validity Period greater than 398 days.
- Effective 2021‐10‐01, for validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.
Under these provisions, the maximum validity period and maximum re-use of domain validation for TLS certificates roughly corresponds to the typical minimum period of time for owning a domain name; i.e. one year. Assuming that most website operators correctly protect the private keys for their TLS certificates for the duration of the time that they own the domain name, these provisions reduce the risk of potential exposure of the private key of each TLS certificate that is revoked, replaced, or no longer needed by the original certificate subscriber.
We still need to take into account situations in which the private key of a TLS certificate is obtained by an attacker or otherwise compromised. This can happen at any time during the certificate’s validity period if the website’s servers become compromised.
Possession of a compromised private key for a TLS certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (public WiFi, local network compromise) or very broad (DNS servers, governments). An attacker armed with the private key of a TLS certificate and an ability to control their victim’s network could impersonate the website corresponding to the compromised certificate in a way that would be undetectable to most users. Then even vigilant end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) because they believe it is coming from a trusted site.
An attacker armed with a compromised private key for a TLS certificate and an ability to control their victim’s network can:
- Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the TLS certificate of the fake site is valid.
- Re-direct users to a fake site -- Users on a compromised network could be directed to a website using a fraudulent certificate and mistake it for the legitimate site.
- In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing). Many users might not notice this and end up logging into an attacker’s website.
Challenges
When a CA has to declare that a cert that used to be valid is no longer valid, we would like to ensure that this information is propagated to browsers as quickly as possible, but we also need to make sure that revocation mechanisms don't harm the user experience, in particular that they:
- Don't add latency to TLS connection establishment
- Don't require clients to store large amounts of data
- Don't reveal more private information than necessary
Revocation should result in “hard fail” to the greatest extent possible. This means that Firefox should assume the certificate is invalid if it cannot determine the revocation status. The opposite is called “soft fail”, in which Firefox assumes the certificate is valid if it cannot determine the status via some supported form of revocation checking.
The standard approach to revocation checking is to use Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP). This has several drawbacks:
- Revocation checking through CRLs or OCSP requests has high latency, even when it succeeds. CRLs can be an especially big hit to performance because they can grow to multiple megabyte files that must be downloaded before displaying a web page.
- When OCSP fails or is blocked (e.g., by a captive portal), the page load can stall for up 15 seconds while the OCSP request times out.
- The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP request to its servers.
- Because OCSP requests fail so often, failures result in certificate acceptance ("soft-fail"), which doesn’t actually protect users from an attack. (i.e. "soft-fail revocation checks are like a seat-belt that snaps when you crash").
OCSP stapling addresses some of these problems, removing the latency and privacy harm when a good OCSP response is available. However, it still has the "soft-fail" problem -- an adversary can suppress the OCSP response.
Our overall goal is to make revocation checking faster and more private, while maximizing the probability that any individual HTTPS connection will get good revocation information. We leverage several approaches here:
- Centralized collection of revocation information and push to Firefox
- Exemption of short-lived certificates from revocation checking
- OCSP stapling with a must-staple indicator
Revocation Processing for Intermediate CA Certificates
The relatively small number and low revocation frequency of CA certificates means that mechanisms that deliver a complete set of revoked certificates to Firefox are practical. However, due to the problems listed above, Firefox never attempts to download CRLs to the client. OCSP is also not used by Firefox to validate CA certificates.
OneCRL
In 2015, Mozilla introduced OneCRL. We gather CA certificate revocation information centrally, then push it out to clients. OneCRL currently contains two types of revocations:
- All CA certificates that have been revoked by the CA. Mozilla now requires CAs to disclose all unconstrained CA certificates in CCADB. From this master list, Mozilla collects revocation information and periodically (usually on a monthly basis) updates OneCRL.
- Exceptional revocations for both CA and end-entity certificates, including some that are not revoked by the CA. These entries are manually processed by Mozilla, typically as the result of a security incident involving the certificate.
Revocations in OneCRL are typically based on the serial number and issuer of the revoked certificate. If multiple certificates with the same subject and public key need to be revoked, revocations based on the subject and public key hash are also supported.
Multi-staple
RFC 6961 defines a mechanism for stapling OCSP responses for CA certificates. Since FIrefox does not rely on OCSP to validate intermediate certificates, we have no plans to implement support for this.
Revocation Processing for End-Entity Certificates
Revocation of end-entity certificates is checked in Firefox using the following mechanisms.
Short-Lived Certificates
A certificate with a must-staple extension is basically equivalent to a certificate with the same lifetime as the stapled OCSP response. (The only difference is that the OCSP response can be signed by a delegated key pair.) If the CA simply issues certificates with a lifetime on the order of an OCSP response, then there is no security benefit to performing revocation checking on these certificates. (This is basically the same approach taken by DNSSEC, which has short-lived signatures and no revocation.)
Like OCSP must-staple, short-lived certificates are another fast-path option for websites, since a supporting browser will skip all revocation checks. Using short-lived certificates instead of a must-staple extension also removes the need to send an OCSP response in the handshake.
Firefox does not perform any form of revocation checking for certificates with a validity period of less than 10 days. That period is configurable via the security.pki.cert_short_lifetime_in_days preference.
OCSP Stapling
OCSP stapling is a mechanism by which the web server periodically retrieves a fresh OCSP response from the CA and delivers it to the client in the TLS handshake. This eliminates the separate connection to a CA’s OCSP server that introduces latency and leaks browsing information. However, OCSP stapling is still susceptible to network failures and attacks. When Firefox receives a valid stapled OCSP response, it processes the response and does no other revocation checking. If the security.OCSP.enabled preference is set to ‘0’, stapled OCSP responses are ignored.
OCSP Must-staple
OCSP stapling allows good certificates to save the latency of a live OCSP fetch, but they don't provide much security benefit, since an attacker can omit the stapled response, suppress the live OCSP response, and soft-fail their way to victory. The TLS Feature Extension for certificates protects against this attack by allowing the certificate to signal the browser to hard-fail if a stapled OCSP response is not present. When an end-entity certificate with the proper value in this extension is evaluated by Firefox, the stapled OCSP response will always be processed. If the response is not delivered via the TLS handshake or is not valid, Firefox will display an error rather than falling back to regular OCSP. Must-staple may be disabled via the security.ssl.enable_ocsp_must_staple or the security.ssl.enable_ocsp_stapling preferences.
OCSP
Firefox currently relies on traditional OCSP when a certificate is delivered without a stapled OCSP response. By default, Firefox ignores the revocation check (i.e. soft-fails) if a valid response is not received from the OCSP server within 2 seconds (10 seconds for an EV certificate). Setting the security.ocsp.require preference to ‘1’ switches to hard fail and triggers a certificate validation error if an OCSP response is not received within 10 seconds.
If the OCSP server returns a status of “unknown”, Firefox will display the “SEC_ERROR_OCSP_UNKNOWN_CERT” error in a non-overrideable error message, regardless of the security.ocsp.require preference. Similarly, if the OCSP responder returns an error such as “trylater”, Firefox will display an error message.
Notes:
- Firefox no longer performs OCSP fetching using the HTTP GET method; Firefox uses the HTTP POST method.
- Firefox caches OCSP responses until they expire or Firefox is restarted (the cache is not persistent).
- If an OCSP response has no "nextUpdate", it is valid for 24 hours (plus "slop" of another 24 hours to deal with clock skew).
- The maximum lifetime of an OCSP response for an end-entity is 10 days, even if the the "nextUpdate" value is farther in the future.
CRLite
Mozilla is currently (as of early 2019) preparing to test an out-of-band revocation mechanism based on an academic paper titled “CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers”. In this mechanism, Mozilla produces a highly compressed representation of all trusted, non-expired certificates found in Certificate Transparency (CT) logs and their revocation status as asserted by the corresponding CRL. CRLite updates are delivered to the client using the same mechanism as OneCRL.
Once fully implemented, CRLite is expected to be the primary mechanism used by Firefox to validate end-entity certificates. We expect that revocation checking will fall back to OCSP stapling or OCSP in the following situations:
- If a CA has opted not to log a certificate, then it will not be delivered to the browser with any SCTs from recognized CT logs. When this happens (even for logged certificates), Firefox will fall back to OCSP stapling or OCSP in a hard-fail mode of operation for revocation checking.
- There will be a small period of time - typically less than a day - after a certificate is first logged when CRLite won’t know about it and thus may not provide the correct revocation status. If the client’s latest update is timestamped after the date of the earliest SCT, then revocation checking will fall back to OCSP stapling or OCSP.
- There may be certain cases in which all certificates signed by a specific CA certificate are not included in CRLite data. For example, if a CA doesn’t supply CRLs Mozilla may choose to exclude it, resulting in the use of OCSP for all certificates issued by that CA.
- An enterprise policy and preference will be available to allow organizations to disable CRLite in certain situations, such as when they choose not to log specific publicly-trusted certificates or install their own private roots.
Extended Validation Rules
In order to receive the EV UI, end-entity revocation checking must succeed via one of the currently implemented revocation checking mechanisms described above. If the security.OCSP.enabled preference is set to ‘0’ (disabled), OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.
Enterprise PKIs
The Baseline Requirements forbid publicly-trusted CAs from issuing certificates without revocation pointers. For reasons of compatibility with other PKIs, such as enterprise PKIs, Firefox currently accepts such certificates if they are otherwise valid, and will continue to do so.
