CA:RevocationPlan
Redirect to:
This page documents Mozilla's future plans regarding how we support revocation checking of SSL certificates.
- Discussion of policy changes: mozilla.dev.security.policy forum
- Discussion of code changes: mozilla.dev.tech.crypto forum
Revocation Is Important
Support for revoking certificates is important, because otherwise stolen certificates can be used to abuse our users until they expire. History, from Diginotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Having no revocation story is not an option.
Problem Statement
Every so often, 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 state
- Don't reveal more private information than necessary
Revocation should result in hard failure to the greatest extent possible. If a certificate is verifiably revoked, then the browser should not proceed with the connection -- and we should always be able to determine whether a certificate has been revoked.
The current approach to revocation checking is to use OCSP. This has several drawbacks:
- Revocation checking through OCSP requests has high latency, even when it works.
- When OCSP fails or is blocked (e.g., by a captive portal), the page load can stall for up 30+ seconds while we 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.
- Revocation of intermediate certificates is only checked during EV validation.
- Because OCSP requests fail so often, failures result in certificate acceptance ("soft-fail"), which fails to protect users. (As AGL puts it, "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 plan to leverage several approaches here:
- Centralized collection of revocation information and push to browsers
- Exemption of short-lived certificates from revocation checking
- OCSP stapling with a must-staple indicator
Our hope is that these solutions together will cover a sufficiently large number of use cases that the use of "live" OCSP will become small enough to let us hard-fail when OCSP fails. If live OCSP is sufficiently rare, then it will be easier for us to enable hard-fail by default -- in order for a web site to be broken, it will have had to decline to use all of the above mechanisms, and use a CA with a broken OCSP responder.
Long-range Vision
To put it briefly: For CA certificates (that is, roots and subCA certificates), only check a centralized list. For EE certificates, provide a collection of "fast path" options. The proposed changes in validation processing are illustrated in this PDF.
- Mozilla maintains central list of revocation information (called OneCRL), covering all intermediate certificates and an (initially small) subset of EE certificates.
- OneCRL is pushed out to Firefox instances regularly
- For CA certificates, the only revocation checking done is to check the OneCRL
- For EE certificates, Firefox checks several revocation paths:
- OneCRL (if applicable)
- Short-lived certificates are exempted from revocation checking
- Stapled OCSP response (if present)
- OCSP must-staple (if present)
- Live OCSP with hard-fail
Enabling hard-fail on live OCSP by default may not be achievable, and is a long-term goal in any case. We will proceed by implementing the fast-path options first, and measuring (1) how much they reduce live OCSP usage and (2) OCSP failure rates.
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.
Proposed Changes
OneCRL
The idea for OneCRL is to follow a similar approach to the CRLset concept used in Google Chrome (also discussed earlier on a Mozilla wiki page). Gather revocation information centrally, then push it out to browsers. The main questions are thus: (1) What information should we gather?, and (2) How should it be pushed to browsers? (3) How should it be used by the browser?
What to include in OneCRL: The main focus of OneCRL is to cover intermediate CA certificates. So we will need to collect URLs for sources of revocation information for all intermediate CAs. We may well also use it for high-profile EE misissuances. In the future, once the initial implementation is working, we may look into covering EE certificates with OneCRL, possibly focusing initially on specific classes (e.g., EV certificates).
Distribution and Security of OneCRL: Logically, OneCRL updates will be distributed to browsers regularly (roughly daily). In order to ensure that browsers have timely revocation information, we need to ensure that it is difficult for an adversary to block the channel by which these updates are sent out.
Format and Usage of OneCRL: For CA certificates, we will include revocation information by explicitly representing revoked certs (directly or with a fingerprint). Thus, for CA certificates, OneCRL will be dispositive -- a certificate will be rejected if it is in OneCRL and accepted if not. (If OneCRL is updated in the future to cover EE certificates, it will likely require the use of a probabilistic, compressed representation, such as a Bloom filter. In this case, OneCRL will be dispositive only in the positive direction: If the certificate is covered by OneCRL and the certificate is not listed as revoked, then we know it is not revoked. But if the certificate is in OneCRL, then we still check OCSP (stapled or live) to for false positives).
Next Steps
- Complete implementation of block-list-based OneCRL
- Add support for CRL polling as an input, as well as manual input
- Collect URLs for revocation information covering all intermediate CAs
- Investigate whether there are some EE certificates that should be covered by OneCRL
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 his way to victory. The OCSP must-staple extension for certificates protects against this attack by allowing the browser to fail if a stapled OCSP response is not present. This also represents a guaranteed fast-path option for websites, since a certificate with this extension will never have a live OCSP lookup (at least for browsers that support the extension).
The specification for the must-staple extension is currently being developed in the IETF. As this specification is finalized, we plan to add support for it to the Firefox certificate validation process.
Next Steps
- Support standardization of must-staple extension
- Implement support for must-staple extension
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.
The proposal here is thus to set a threshold maximum lifetime, and for certificates whose lifetime is shorter than that threshold, perform no further revocation checking.
The question is then what threshold we should use. As a starting point, Firefox currently limits OCSP validity times to a maximum of 10 days. We could also look at some empirical data on he distribution of OCSP validity times to see if something shorter might make sense. The setting of a threshold should obviously be done in coordination with CAs and website owners, since it will impact their operations. For example, it might be helpful for the CA/Browser Forum to establish a recommendation.
Next Steps
- Agree on a threshold with other stakeholders
- Add a check for short-lived certificates, and exemption from revocation checking
- Agreement on a threshold is required before this is enabled on a broad scale
Hard-fail Measurement & Enablement
In the long run, we would like to make live OCSP checks hard-fail by default when the browser is unable to reach an OCSP responder. But of course, as long as we are heavily reliant on live OCSP checks for revocation for most HTTPS transactions, the breakage caused by hard-fail is too high. We should monitor the level of breakage that hard-fail would cause to see if we can get to a low enough level that we can turn on hard-fail.
Next Steps
- Add measurements of how often the various revocation paths are taken, in particular, how often live OCSP is used and how often it fails
- Establish measurements of (1) live OCSP usage rate and (2) live OCSP failure rate
What Do Others Do?
Chrome on Desktop
Google Chrome only uses CRLsets for non-EV (and some EV?) certs. However, their CRLset implementation covers both end-entity and intermediate certs, and is not designed to be comprehensive. Some CRLs are not included - the list is manually mantained by emailing agl.
agl is of the opinion that the only thing other than CRLsets which is worth considering is must-staple. So Chrome seems to be going in the same direction as us.
IE on Desktop
IE checks OCSP and, if OCSP fails, falls back to CRLs - although they are considering eliminating the fallback.
Chrome on Mobile
???
Android Browser
???