MozillaWiki

CA:ImprovingRevocation: Difference between revisions

Page Discussion

CA:ImprovingRevocation (view source)

Revision as of 23:10, 19 February 2019

3,595 bytes removed ,  19 February 2019
Redirect to new version of this page
No edit summary
(Redirect to new version of this page)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
#REDIRECT [[CA/History_of_Revocation_Checking]]
= 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.
See [[CA:RevocationPlan | CA:RevocationPlan]] for Mozilla's plans regarding how we will support revocation checking of SSL certificates.
 
This page is dedicated to changes that are happening to move towards our [[CA:RevocationPlan#Long-range_Vision | long-term revocation goals]].


* Discussion of Policy changes: '''mozilla.dev.security.policy''' forum
* Discussion of Policy changes: '''mozilla.dev.security.policy''' forum
Line 9: Line 13:
[[File:SSLcertRevocation.pdf]]
[[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.
== 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.
 
[http://tools.ietf.org/html/rfc7633 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: [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html ''Discussion Thread'']
 
* Code Change: {{Bug|901698}}, {{Bug|921907}}
 
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | 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 [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ 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: [[CA:RevokedSubCAcerts|https://wiki.mozilla.org/CA:RevokedSubCAcerts]]
 
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]
 
* Code Change: {{Bug|1024809}}


== Problems to Solve ==
* Policy Change:
** https://wiki.mozilla.org/CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce
** https://github.com/mozilla/pkipolicy/issues/48


Here are some of the issues that we hope to address very soon.
==== When To Notify Mozilla ====
* 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.
CAs must notify Mozilla of all revoked non-technically-constrained intermediate certificates chaining to a root certificate included in [[CA:IncludedCAs|Mozilla's root store]] that are revoked before the certificate has expired.
* 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.
When a CA revokes an intermediate certificate chaining to a root certificate included in [[CA:IncludedCAs|Mozilla's root store]], the CA '''must''' notify Mozilla if the certificate was revoked for one or more of the following reasons. '''Time Frame''' for such notification: within 24 hours of revocation of the intermediate certificate
* 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.
* Cessation of business operation - An externally-operated subordinate CA certificate has been revoked or replaced (for any reason) before it has expired.
* According to [http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf 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)


== Changes '''Completed/Released''' ==
'''Time Frame''' for Notification: within 24 hours of revocation of an intermediate certificate


The following changes have been implemented and released.
'''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.
* Otherwise, enter the data about the revoked intermediate certificate into the [[CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce|Common CA Database]].


=== No EV Treatment when OCSP Fails or Not Provided ===
=== 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.  
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
* Release: Mozilla 28


* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ mozilla.dev.security.policy]
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ mozilla.dev.security.policy]
Line 49: Line 100:
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/


* Release: Firefox 26  
* Release: Mozilla 26  


* Discussion: This has been discussed in several forums.
* Discussion: This has been discussed in several forums.
Line 63: Line 114:
* Process Change: None
* Process Change: None


=== Reduce OCSP Network Timeout for EV and Soft-Fail ===
=== Reduce OCSP Network Timeout for Soft-Fail ===
Reduce OCSP network timeout. When the OCSP preference is set to soft fail or when EV 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 and the certificate validation is non-EV, the network timeout will still be 10 seconds.  
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
* Release: Mozilla 27
Line 81: Line 132:
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 [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].  
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 [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].  


* Release: Firefox 24  
* Release: Mozilla 24  


* Discussion:  
* Discussion:  
Line 100: Line 151:


* Process Change: Update the [https://wiki.mozilla.org/CA:Information_checklist Root Inclusion Checklist] to provide information about how to manually test CRLs in NSS using [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil].
* Process Change: Update the [https://wiki.mozilla.org/CA:Information_checklist Root Inclusion Checklist] to provide information about how to manually test CRLs in NSS using [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil].


== Changes '''In Progress''' ==
== Changes '''In Progress''' ==
Line 166: Line 216:


* 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.
* 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 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: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]
* 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 [http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf 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 ===
=== Preload Revocations of Certain End-Entity Certificates ===
Line 238: Line 240:


'''How''' to notify Mozilla of a revocation: Same method as used 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.
=== 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.
[http://www.ietf.org/mail-archive/web/tls/current/msg10323.html IETF is working on a standardized must-staple mechanism], but it will be a long time before all CAs in our program have deployed that extension in all of the certificates they issue.
As an interim measure, we plan to implement a must-staple mechanism that any website can deploy that does not require the cooperation of any CA. The mechanism will be based on a Must-Staple HTTP header, analogous to the Strict-Transport-Security and the Public-Key-Pins mechanism being worked on in the IETF. For example, “Must-Staple: max-age=10886400; includeSubdomains” in a response to an HTTPS request on a connection with a valid certificate and a stapled OCSP response would cause the browser to reject any TLS handshake for that domain (and all subdomains) that does not include a stapled OCSP response.
This mechanism would suffer from the same first-visit problem that Strict-Transport-Security and Public-Key-Pins suffer from, but we can mitigate all these issues through the preloaded list mechanism that we're already using for HSTS.
http://www.ietf.org/mail-archive/web/tls/current/msg10351.html
* Discussion: ''Link to Discussion Thread''
* Code Change: {{Bug|901698}}, {{Bug|921907}}
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]], insanity::pkix {{Bug|915930}}
* Policy Change: To be determined.


* Process Change: To be determined.
* Process Change: To be determined.
Wthayer
136

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/948607...1207948"