CA/History of Revocation Checking

From MozillaWiki
< CA
Jump to: navigation, search

History of Revocation Checking Improvements in Firefox

This page is a historical record of revocation checking improvements made to Firefox as of March 2017.

This page is outdated and exists for reference only!

Current Information on Revocation Checking in Firefox

Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: File:SSLcertRevocation.pdf

Changes Completed/Released

The following changes have been implemented and released.

OCSP Must-Staple

Websites that implement OCSP Must-Staple will get Hard Fail Revocation. A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled. The IETF have specified a standard mechanism, which is implemented in Firefox Nightly. This is expected to ship with Firefox 45.

  • Release: Mozilla 45
  • Discussion: Discussion Thread
  • Code Change: bug 901698, bug 921907
  • Dependencies: OCSP Stapling, insanity::pkix bug 915930
  • Policy Change: None, though Must-Staple is a popular subject for proposals permitting "not short-lived" certificates in the future.
  • Process Change: None needed.

Preload Revocations of Intermediate CA Certificates

Push revocation information of revoked intermediate CA certificates to clients. Mozilla has implemented a revocation list push mechanism in Firefox called OneCRL, which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. Further information about revoked intermediate certificates: https://wiki.mozilla.org/CA:RevokedSubCAcerts

No EV Treatment when OCSP Fails or Not Provided

EV Treatment will not be given when the OCSP response fails or cannot be retrieved for end-entity and intermediate certificates.

  • Release: Mozilla 28
  • Dependencies: OCSP Stapling
    • Some sites that are currently receiving EV treatment may stop getting EV treatment. If that happens, check that the OCSP URI is in the AIA of the end-entity and intermediate certificates (unless stapled OCSP response is provided), and that the OCSP responses are correctly being returned.
  • Policy Change: None. The EV guidelines already require OCSP.
  • Process Change: None. We already check for this when evaluating EV root inclusion/change requests.

OCSP Stapling

OCSP responders are not yet reliable enough for us to do hard fail. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail.

OCSP stapling has the site itself periodically ask the CA for a signed assertion of status and sends that statement in the TLS handshake at the beginning of new HTTPS connections. The browser takes that signed, stapled response, verifies it, and uses it to determine if the site’s certificate is still trustworthy.

https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/

  • Release: Mozilla 26
  • Discussion: This has been discussed in several forums.
  • Policy Change: None
  • Process Change: None

Reduce OCSP Network Timeout for Soft-Fail

When the OCSP preference is set to soft fail(default) and DV validation is being performed, the network timeout will be changed from 10 seconds to 3 seconds. When the OCSP preference is set to hard fail or EV validation is being performed, the network timeout will still be 10 seconds.

  • Release: Mozilla 27
  • Dependencies: None
  • Policy Change: None
  • Process Change: None

Remove CRL User-Interface

As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a revocation list push mechanism.

  • Release: Mozilla 24
  • Dependencies: None.
    • Use crlutil to see and/or modify your list of CRLs in NSS.
    • The feature of auto-importing/updating CRLs through Firefox is gone, because CRLs won't be updated any more by Firefox. If you have another program that is adding/updating your CRLs in your NSS certificate database, then those CRLs will be used for the time being.
    • In the near future Firefox will not be checking CRLs that have been imported into NSS. Instead, Firefox will use a revocation list push mechanism.
  • Policy Change: No policy change for this, because CRLs are still supported in NSS so CRLs can continue to be used without the UI. Also, there are non-Mozilla products that use NSS and may continue to rely on CRLs.

Changes In Progress

The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.

OCSP GET

Change OCSP client code to try HTTP GET first, and fall back to POST in case GET fails. GET has the advantage that it can be cached by an ordinary caching HTTP server. It is also possible for an OCSP responder to redirect a GET request, but not a POST request.

  • Release: NSS 3.15.4, Firefox ???
  • Discussion: Link to Discussion Thread
  • Dependencies: None
  • Policy Change: None
  • Process Change: None

Proposed Changes under Discussion

The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.

Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.

Remove CRL Checking via CRLDP

Remove CRL checking through CRLDP in the certificate (a.k.a. CRL fetching). The normal certificate checking path does not do CRL fetching, and it never has. So, for any CA that isn't enabled for EV treatment, Firefox has never done CRL fetching. Firefox has only done CRL checking for EV certs as per the following logic. The source code for this is here: http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150

  1. Does the end-entity certificate have an EV policy OID from any of the CAs that have been enabled for EV treatment.
  2. If yes, then verify that the certificate is valid for that policy OID, trusting only that CA's root.
  3. During this validation, check OCSP, and fall back to CRLs using CRLDP.
  4. If that validation succeeds, then return "Good EV certificate."
  5. If that validation fails, check the certificate using the normal certificate checking path.

The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon.

Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library.

  • Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.

Preload Revocations of Certain End-Entity Certificates

Push revocation information of certain revoked end-entity certificates to clients.

Implement a revocation list push mechanism in Firefox, which will push revocation lists of end-entity certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This should only apply to certain revocation circumstances in order to keep the list small/manageable.

  • Discussion: Link to Discussion Thread
  • Code Change: Bugzilla Bug Number
  • Dependencies:
    • Will need to be very specific about the circumstances for which we want to include revocation information for end-entity certs.
    • Will require a notification mechanism for CAs to inform us of which end-entity certs to add to the revocation list.
  • Policy Change: Will need to discuss.

When To Notify Mozilla: CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as:

  • Wrong Key Usage
  • Certificate issued for a domain to somebody that doesn't own/control that domain
  • Mistakenly set isCA=true

Time Frame for Notification: Same time frame as for revocation of intermediate certs?

How to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?

  • Process Change: To be determined.
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/History_of_Revocation_Checking&oldid=1237534"