136
edits
Changes
Initial page creation
== 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.
== 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 state
* 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 ([http://tools.ietf.org/html/rfc6960 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. [https://www.imperialviolet.org/2012/02/05/crlsets.html "soft-fail revocation checks are like a seat-belt that snaps when you crash"]).
[http://tools.ietf.org/html/rfc6066 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 [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ 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 [https://ccadb.org/ 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 ===
[https://tools.ietf.org/html/rfc6961 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.
Unfortunately, the adoption of short-lived certificates has been hampered by current CA/Browser Forum rules requiring OCSP for all certificates.
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 ===
[https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ 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 [http://tools.ietf.org/html/rfc7633 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.
Note: Firefox [https://bugzilla.mozilla.org/show_bug.cgi?id=871954#c7 no longer] performs OCSP fetching using the HTTP GET method.
=== CRLite ===
Mozilla is currently (as of early 2019) preparing to test an out-of-band revocation mechanism based on an [https://mislove.org/publications/CRLite-Oakland.pdf 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. In addition, as part of EV processing, OCSP is used in addition to OneCRL to check revocation for intermediate CA certificates. If an OCSP response for the intermediate CA certificate is not received or fails to verify, then the EV UI will not be displayed. Finally, 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.
== History of Revocation Checking Improvements in Firefox ==
[[History of Revocation Checking|A partial history of changes made to Firefox as of March 2017 in support of better revocation checking has been preserved.]]
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.
== 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 state
* 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 ([http://tools.ietf.org/html/rfc6960 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. [https://www.imperialviolet.org/2012/02/05/crlsets.html "soft-fail revocation checks are like a seat-belt that snaps when you crash"]).
[http://tools.ietf.org/html/rfc6066 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 [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ 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 [https://ccadb.org/ 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 ===
[https://tools.ietf.org/html/rfc6961 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.
Unfortunately, the adoption of short-lived certificates has been hampered by current CA/Browser Forum rules requiring OCSP for all certificates.
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 ===
[https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ 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 [http://tools.ietf.org/html/rfc7633 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.
Note: Firefox [https://bugzilla.mozilla.org/show_bug.cgi?id=871954#c7 no longer] performs OCSP fetching using the HTTP GET method.
=== CRLite ===
Mozilla is currently (as of early 2019) preparing to test an out-of-band revocation mechanism based on an [https://mislove.org/publications/CRLite-Oakland.pdf 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. In addition, as part of EV processing, OCSP is used in addition to OneCRL to check revocation for intermediate CA certificates. If an OCSP response for the intermediate CA certificate is not received or fails to verify, then the EV UI will not be displayed. Finally, 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.
== History of Revocation Checking Improvements in Firefox ==
[[History of Revocation Checking|A partial history of changes made to Firefox as of March 2017 in support of better revocation checking has been preserved.]]
