CA:ImprovingRevocation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
{{DRAFT}}
* '''Policy changes to be discussed in the mozilla.dev.security.policy forum'''
* '''Code changes to be discussed in the mozilla.dev.tech.crypto forum'''
= Plan for Improving Revocation Checking in Firefox =
= Plan for Improving Revocation Checking in Firefox =


This page is dedicated to improving how Firefox does revocation checking of SSL certificates.
This page is dedicated to improving how Firefox does revocation checking of SSL certificates.
* '''Discussion of Policy changes: mozilla.dev.security.policy forum'''
* '''Discussion of Code changes: mozilla.dev.tech.crypto forum'''
Results of a research project investigating the state of SSL Certificate Revocation:
[[File:SSLcertRevocation.pdf]]


The traditional X.509 CRL and OCSP mechanisms treat all possible reasons for revocation uniformly for all websites. This uniformity leads directly to the scalability problem of revocation checking: relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations. The key to efficient, scalable processing of revocations in the short term is to realize that there are multiple possible ways for revocation information to be retrieved and that the choice of retrieval method can be made on the basis of the reason for revocation.
The traditional X.509 CRL and OCSP mechanisms treat all possible reasons for revocation uniformly for all websites. This uniformity leads directly to the scalability problem of revocation checking: relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations. The key to efficient, scalable processing of revocations in the short term is to realize that there are multiple possible ways for revocation information to be retrieved and that the choice of retrieval method can be made on the basis of the reason for revocation.

Revision as of 19:11, 8 October 2013

Plan for Improving Revocation Checking in Firefox

This page is dedicated to improving how Firefox does revocation checking of SSL certificates.

  • Discussion of Policy changes: mozilla.dev.security.policy forum
  • Discussion of Code changes: mozilla.dev.tech.crypto forum

Results of a research project investigating the state of SSL Certificate Revocation: File:SSLcertRevocation.pdf

The traditional X.509 CRL and OCSP mechanisms treat all possible reasons for revocation uniformly for all websites. This uniformity leads directly to the scalability problem of revocation checking: relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations. The key to efficient, scalable processing of revocations in the short term is to realize that there are multiple possible ways for revocation information to be retrieved and that the choice of retrieval method can be made on the basis of the reason for revocation.

Problems to Solve

Here are some of the issues that we hope to address very soon.

  • Currently revocation of intermediate certificates is only checked during EV validation. Sadly, the intermediates we do check revocation for (EV) are the ones that are the least likely to cause our users security problems.
  • 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 to its servers.
  • Revocation checking through OCSP and CRL requests is way too slow.
  • Many captive portals with HTTPS login pages work very poorly in Firefox because it stalls for 30+ seconds waiting for the OCSP response for the captive portal that is being blocked by the captive portal until the user logs in.
  • If revocation checking via OCSP/CRL fetching for an EV certificate fails, then EV treatment is not given, which may cause confusion. This is particularly problematic for cases when a web app is designed to be used offline (e.g. using AppCache), but even normal websites are affected by this. This inconsistency in the security indicators devalues the security indicators.

These problems can be solved, but they cannot be solved overnight, and they cannot be solved without cooperation from our partners on the internet: certificate authories and websites. We need to quickly provide our partners with useful and working tools, so they can adapt to improve the security of the internet. The most achievable way to do this is to stretch existing, already-standardized and easily-deployable (if not already widely-deployed) mechanisms so that they actually address our users' needs in a reasonable way.

Changes In Progress

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

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: Target is mozilla25
  • 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 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: Firefox 25
  • Discussion: This has been discussed in several forums.
  • 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: Firefox 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.

Change Name

Description

  • Release: to be determined
  • Discussion: Link to Discussion Thread
  • Code Change: Bugzilla Bug Number
  • Dependencies:
  • Policy Change:
  • Process Change:

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.

Preload Revocations of Intermediate CA Certificates

Push revocation information of revoked intermediate CA certificates to clients.

Implement a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve 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.

We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)

  • Discussion: Link to Discussion Thread
  • Code Change: Bug Number
  • Dependencies:
    • This will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list previous relevant revocations.
    • Will require a notification mechanism for CAs to inform us of which certs to add to the revocation list.
    • In the short term, we will (probably) respond to the revocation notification by issuing a browser security update that contains the updated list of revoked certificates. In the long term, we may have a lighter-weight mechanism for updating the browser with updated revocation information, similar to Google's CRLSet mechanism.
  • Policy Change: To be discussed and proposed in the mozilla.dev.security.policy forum.

When To Notify Mozilla:

  • Technical Issue - There is a problem with the intermediate certificate such that the certificate may be inappropriately used. This includes, but is not limited to, wrong key usage, incorrect name constraints, etc.
  • An externally-operated subordinate CA certificate has been revoked or replaced (for any reason) before it has expired.
  • Cessation of business operation. (Is this one covered by the previous bullet point?)
  • According to NIST IR 7924 a Trust Anchor Manager (TAM) is an Authority who manages a repository of trusted Root CA Certificates. As specified in Section 5.7, the TAM will require the CA to provide notification when:
    • Root CA compromise -- Compromise of CA private signing key (Notification shall be made in an authenticated and trusted manner... earliest feasible time and shall not exceed <24> hours beyond determination of compromise or loss unless otherwise required by law enforcement)
    • Intermediate or Subordinate CA key compromise (revocation information shall be published immediately in the most expedient, authenticated, and trusted manner but within <18> hours)
    • Compromise of Certificate Status Server (CSS) key, an example of a CSS is an OCSP server. (If the CSS is self-signed and the CSS certificate expiration is more than <7> days away, the vendor shall immediately notify the trust anchor managers)
    • RA key compromised (the revocation information shall be published within <24> hours in the most expedient, authenticated, and trusted manner)
    • Suspected or detected compromise of any CA system or subsystem
    • Physical or electronic penetration of any CA system or subsystem
    • Successful denial of service attacks on any CA system or subsystem
    • When computing resources, software, and/or data are corrupted
    • Any incident preventing a CA from issuing and publishing a CRL or OCSP prior to the time indicated in the nextUpdate field in the currently published CRL or OCSP suspected or detected compromise of a certificate status server (CSS) if
      • the CSS certificate has a lifetime of more than <72> hours; and
      • the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension)

Time Frame for Notification: within 24 hours of revocation of an intermediate certificate

How to notify Mozilla of a revocation

  • If the revocation is due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org.
  • To notify us of an intermediate certificate revocation, submit a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. Whenever possible, the CA should send us the revoked certificate itself, along with the rfc5280 revocation reason code. If the CA cannot send us the revoked certificate, then the information listed below will be needed.
    • Serial number of the revoked certificate
    • Link to the OCSP response for that serial number
    • Link to the CRL that contains that serial number
    • notAfter date of the revoked certificate
    • rfc5280 revocation reason code
  • Process Change: To be determined, but may include changes to the Inclusion Process, and EV treatment (maybe EV treatment is only granted when the CA is providing this information?)

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.

Change Name

Description

  • Discussion: Link to Discussion Thread
  • Code Change: Bugzilla Bug Number
  • Dependencies:
  • Policy Change:
  • Process Change:
Retrieved from "https://wiki.allizom.org/index.php?title=CA:ImprovingRevocation&oldid=724741"