136
edits
Changes
Initial copy moved from CA:MaintenanceAndEnforcement
= Maintaining Confidence in Root Certificates =
Mozilla's efforts to maintain confidence in root certificates include:
# Carefully reviewing CA applications for root inclusion.
#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses
#* A Mozilla representative checks the CA's CP/CPS documentation for
#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]
#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Recommended Practices] (if issues are noted, they are discussed to determine of the CA takes appropriate measures to protect end-users), and
#** avoidance of [https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices Mozilla's list of Potentially Problematic Practices] (if found, further questions and discussion follow to evaluate if the CA's measures are sufficient to protect end-users).
#* A Mozilla representative confirms that the CA has been audited as per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy.]
# Keeping a record of current audit statements for each CA.
#* [https://wiki.mozilla.org/CA/IncludedCertificates Table of included root certs and their corresponding documentation and current audit statements]
#* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters Mozilla's Root Store Policy] states that CAs must conduct period-of-time audits and provide updated publicly-available audit documentation no less frequently than annually..
# Updating policies and practices as issues are found/realized, communicating updates and recommendations to CAs, and tracking CA responses to communications.
#* [https://github.com/mozilla/pkipolicy/issues Issues list for Mozilla’s Root Store Policy]
#* [https://wiki.mozilla.org/CA/Communications CA Communications]
#* If a CA does not respond to Mozilla's communications within the timeframe specified in the communication or does not provide a copy of its annual audit statement within 15 months of the end of its previous annual audit period, then Mozilla may take action up to and including [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#73-removals removal of the root(s) from the program].
# When a potential certificate mis-issuance is noticed by anyone, they should report it by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance creating a bug in the CA Certificate Mis-issuance component]. More information on filing a security-sensitive bug can be found in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy.]
When a security threat or potential certificate mis-issuance arises with a CA in Mozilla's program we consider the impact and risk to the end-users to decide on the action to take. The following considerations are taken into account:
* Magnitude of the threat
** How can the threat or mis-issuance be used by a hacker to put end-users at risk?
** Has all appropriate action been taken by the CA to prevent further impact to end-users?
** What additional actions does Mozilla need to take to protect end-users from the threat or mis-issuance?
*** How will end-users be impacted by Mozilla actions?
*** Can Mozilla take a different action that will protect end-users, but confine noticeable impact to the smallest group possible?
*** Will Mozilla's actions have a worse impact on end-users than the current threat or mis-issuance?
* CA behavior
** Did the CA notice the error and take appropriate action in a timely manner?
*** Was the threat or error properly contained?
** Did the CA notice the hacker intrusion and take appropriate action in a timely manner?
*** Were the CA's defense mechanisms current and sufficient?
*** Was the intrusion appropriately contained?
** Was the CA's behavior reckless?
** Did the CA try to cover up the mistake/threat rather than follow [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy?]
Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's Root Store Policy. Statements obtained from an auditor are assumed legitimate. Audit statements provided by a CA are verified for legitimacy with the auditor. The
qualifications of any auditors not previously approved by Mozilla are reviewed before an audit statement is accepted. Auditor qualifications are reviewed using the webtrust.org website or an appropriate government website. If the auditor claims to be AICPA/CICA/CISA accredited, but the
auditor is not approved by Mozilla and not listed on a trusted website as accredited, then Mozilla will verify the auditor's qualifications with a representative of CICA or CISA, as appropriate.
= Risks to Consumers =
Possession of a mis-issued certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (shared WiFi, local network compromise) or very broad (governments). An attacker armed with a fraudulent certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. The end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) if they believe it’s coming from a trusted site.
An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network can:
* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the SSL certificate of the fake site is valid.
* Re-direct users to a fake site -- Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites.
** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.
= Potential Problems, Prevention, Response=
While CA incidents have differing levels of seriousness, there are some components which every CA should be able to avoid which are red flags for Mozilla in terms of a continued trust relationship, and which would lead to an investigation. They are:
* Deliberate violation of Mozilla or other applicable policy
* Lying or deception
Mozilla will also assess how concerned we are about an issue in part based on how the CA reacts to that issue, and previous ones. In incident response, Mozilla is looking for the following factors:
* A CA takes responsibility for their own actions.
* Incidents are taken with an appropriate level of seriousness.
* Incidents are handled with urgency.
* Root cause analysis is performed.
* Any questions posed, by anyone, are answered quickly and in detail.
* A reasonably-detailed [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report report] is made public on what happened, why, and how things have changed to make sure it won’t happen again.
The following is an enumeration of some of the different kinds of problems that may occur, and what our prevention or immediate response to those problems should be, as long as the CA is demonstrating responsibility and integrity as described above. This is not about meting out punishment, and is not intended to be punitive. Rather, when there is evidence of one of the problems below with a certificate chaining up to a CA in Mozilla's CA Certificate program, we need to take the necessary steps to keep users safe.
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] describes the steps that Mozilla takes to evaluate and respond to security concerns related to certificate operation and issuance. The following list may be used as a guideline of what to expect when certain types of issues are found, but this list is non-binding because the necessary actions and responses will vary depending on the situation.
'''Problem:''' SHA-1 certificate(s) issued
* Prevention: Don't accept SHA-1 certs. {{bug|1339662}}, in Firefox 51.
'''Problem:''' Certificate(s) issued with weak RSA key
* Prevention: Don't accept certs signed with weak RSA keys. {{bug|360126}}, in Firefox 33.
'''Problem:''' Certificate(s) issued without enough key usage info
* Prevention: Enforce key usage restrictions better. {{bug|725351}}, needs to be implemented.
'''Problem:''' CA mis-issued a small number of SSL certificates that they can enumerate
* Immediate Minimum Response: Open a CA compliance bug and request an [CA/Responding_To_An_Incident#Incident_Report incident report].
* Depending on the situation, also consider adding the certificates to OneCRL.
'''Problem:''' CA mis-issued a small number of email certificates that they can enumerate
* Immediate Minimum Response: Actively distrust that set of email certificates in Thunderbird, and push out an update to Thunderbird.
* Depending on the situation, also consider distrusting the intermediate or root certificate that the mis-issued certificates chain up to.
'''Problem:''' CA mis-issued a large number (e.g. hundreds) of end-entity certificates that they can enumerate
* Immediate Minimum Response: Open a CA compliance bug and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
* Depending on the situation, also consider adding the intermediate CA certificate(s) to OneCRL, distrusting the root certificate that the mis-issued certificates chain up to, or all of the root certificates owned by that CA.
'''Problem:''' CA mis-issued an unknown number of un-enumerated end-entity certificates
* Immediate Minimum Response: Actively distrust the intermediate and root certificates that the mis-issued certificates chain up to, and push out an update to all Mozilla products.
* Depending on the situation, also consider distrusting all of the root certificates owned by that CA.
'''Problem:''' CA mis-issued a small number of intermediate certificates that they can enumerate
* Immediate Minimum Response: Actively distrust the intermediate certificates, and push out an update to all Mozilla products.
* Depending on the situation, also consider distrusting the root certificate or all of the root certificates owned by that CA.
'''Problem:''' CA mis-issued an unknown number of un-enumerated intermediate certificates
* Immediate Minimum Response: Actively distrust the root certificate, and push out an update to all Mozilla products.
* Depending on the situation, also consider distrusting all of the root certificates owned by that CA.
'''Problem:''' CA failed to supply proper audit documentation, or audit report contains numerous and/or serious qualifications
* Immediate Minimum Response: File a CA compliance bug and request that the CA respond with remediation plans.
* Depending on the situation, also consider requiring the CA to undergo new period-of-time audits as soon as the problems have been resolved. If the same problems are included on the new audit reports, they must state the dates on which the problems were resolved.
= Ongoing Issues =
In addition to evaluating the severity of a specific incident, Mozilla considers the totality of known issues and patterns of behavior in a CAs response to those issues. When Mozilla believes that sufficient evidence is available, an Issues List may be created. Mozilla will compile the facts of known problems of a particular CA and create a wiki page listing them. Mozilla may then ask the community to consider a response to the set of issues based on the overall risk. This response typically involves distrust of the CAs currently included roots, or requiring the CA to undergo more frequent audits until the Mozilla community’s trust in the CA has been adequately restored.
'''Issues Lists'''
* https://wiki.mozilla.org/CA:PROCERT_Issues
* https://wiki.mozilla.org/CA:Symantec_Issues
* https://wiki.mozilla.org/CA:WoSign_Issues
* https://wiki.mozilla.org/CA:Visa_Issues
= Actively Distrusting a Certificate =
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] and the CA/Browser Forum's Baseline Requirements list some of the reasons why a certificate should be revoked. For the common revocations, CRL and OCSP revocation checking are sufficient. However, in extenuating circumstances, such as those listed above, Mozilla may take additional action to protect users by actively distrusting a certificate.
The steps to actively distrust a certificate are as follows.
# Report security concern
#* When a serious security concern is noticed, such as a root or intermediate certificate compromise, it should be treated as a security-sensitive bug, and the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs] should be followed.
#* As per [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs] a security concern may be reported by sending email to [mailto:security@mozilla.org security@mozilla.org] or by [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security&bug_severity=critical filing a bug.]
# Decide on course of action
#* See [[https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response | Immediate Minimum Responses]] above.
#* Depending on the situation, discussion to determine the course of action may occur in private security group email list and/or in the public mozilla.dev.security.policy forum.
#* The bug will be updated to indicate corresponding decisions.
# Measure Impact of Change
#* Check Firefox telemetry for usage data of the affected root certificate
#* Run [https://tlscanary.mozilla.org/ TLS Canary] in regression mode to determine which websites will be affected.
# Implement Code Change
#* Add the corresponding intermediate or end-entity certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].
#* If it is determined that a certificate needs to be actively distrusted in NSS, then the following will also be done.
#** Update NSS by adding a new entry to the built-in root cert list, to take away trust instead of giving trust. This is done with a separate "distrust" flag, and is called '''Active Distrust'''. Active Distrust can be done for any root, intermediate, or leaf certificate. Active Distrust does not require the entire certificate, because it may be done with a combination of the certificate Serial Number and Issuer. Note: The built-in cert list has two types of entries; cert entries and trust entries. A (dis)trust entry can be added without adding a corresponding cert entry.
#** A problem with this approach arises if the certificate to be Actively Distrusted has been cross-signed with another root certificate that is included in NSS. This could lead us to have to ask every CA in Mozilla's program if they have cross-signed with the root or intermediate certificate that is to be Actively Distrusted. If there is such cross-signing, then the change to the built-in root cert list will also have to include the Issuer/Serial number combination for the cross-signed certificate chain.
# Test
#* Manual testing: Need at least one of the bad leaf certs to make sure the distrust worked.
#* Add test to cert.sh for the ongoing test of the Active Distrust. At minimum, need the intermediate cert for this test. Preferable to also have a leaf cert, which may have been provided when the compromised cert was reported; otherwise would need to request from the CA.
# Release
#* NSS security update, or new version of NSS roots module can be released independently.
#* Depending on the timing and the urgency of the patch, the update may be done either as part of regularly scheduled [https://wiki.mozilla.org/Releases Mozilla releases,] or as a chemspill update (an off-schedule release that addresses live security vulnerabilities). Some Linux users of Firefox use their OS version of NSS, so they would have to make sure that they pick up the new version of NSS.
# Communication / Announcements
#* Announcement in mozilla.dev.security.policy
#* If the Active Distrust is the result of a security incident, then the Mozilla Security Group will assign a [http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures CVE (security incident number)] and reference the new version of NSS or root module.
#* May send an email communication to all CAs, depending on situation.
#* May post in [https://blog.mozilla.org/security/ Mozilla security blog,] depending on situation.
# Result
#* Users will get an error message when they try to browse to a website that uses (or chains up to) the Actively Distrusted certificate.
#* If a cert entry was added to the NSS built-in root cert list, then the Certificate Manager displays the Actively Distrusted certificate in the same manner as other certificates, and the trust bits may be manually turned on by users.
= Concerns =
* Certs that have been mistakenly issued with insufficient key usage can be used maliciously until we implement {{Bug|725351}}.
* The code patch to distrust a cert should only disclose the necessary information; {{Bug|826640}}.
* If the certificate to be distrusted is cross-signed by another certificate in NSS, then the Serial Number and Issuer for that certificate chain also has to be distrusted. This is error-prone, even if we ask every CA in Mozilla's program if they have cross-signed with the certificate to be distrusted.
** Possible Scenario: A cross-signing relationship is overlooked, so the malicious certificate continues to be trusted even after the security update.
** Possible Solution: {{Bug|808839}} - Ability to Actively Distrust all certs with a particular Subject.
* The Certificate Manager does not recognize the "distrust" flag, so there is no distinction in the user interface between certificates that have been Actively Distrusted in NSS and all other certificates. The distrusted certificate(s) should also be added to OneCRL, so the certificate(s) will still be distrusted even if the user manually turns on the trust bits for Actively Distrusted certificates.
** Possible Scenario: User confusion about Actively Distrusted certs listed in the Certificate Manager.
** Possible Solutions: {{Bug|470994}}, {{Bug|733716}}. For Actively Distrusted certs, remove the cert entry from the NSS built-in cert list, and only keep the (dis)trust entry.
* If the certificate to be Actively Distrusted is used by a large portion of the internet population, immediately distrusting the certificate could make many high-traffic websites no longer be reachable, giving the appearance of a large network outage, or users might take actions (such as permanently trusting the bad cert) to bypass error messages.
** Possible Scenario: A root certificate that is chained to by many high-traffic websites is compromised and has to be Actively Distrusted. This is done and an update to Firefox pushed out. Then a large number of users can no longer browse to the high-traffic websites, giving the appearance of an outage, costing those high-traffic websites loss in money, causing frustration and confusion to end users who are regular customers of those websites. Many end-users are likely to manually-override the error, permanently trusting the certificate. Then if they later accidentally browse one of the corresponding malicious websites, they will not get an error.
** Possible Solutions: {{Bug|712615}}, {{Bug|643982}}, or make an announcement that the root will be distrusted on such a date, allowing a small transition time for websites to update their SSL certs before before the Firefox chemspill update is released.
* Distrusting a certificate requires a release to the NSS root module, and users have to choose to upgrade to the new version. Firefox users are protected from distrusted certificates that are added to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].
** Possible Scenario: A user decides not to update their version of NSS, so they continue to trust the certificate in their application.
** Possible Solutions: {{Bug|647868}}
Mozilla's efforts to maintain confidence in root certificates include:
# Carefully reviewing CA applications for root inclusion.
#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses
#* A Mozilla representative checks the CA's CP/CPS documentation for
#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]
#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Recommended Practices] (if issues are noted, they are discussed to determine of the CA takes appropriate measures to protect end-users), and
#** avoidance of [https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices Mozilla's list of Potentially Problematic Practices] (if found, further questions and discussion follow to evaluate if the CA's measures are sufficient to protect end-users).
#* A Mozilla representative confirms that the CA has been audited as per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy.]
# Keeping a record of current audit statements for each CA.
#* [https://wiki.mozilla.org/CA/IncludedCertificates Table of included root certs and their corresponding documentation and current audit statements]
#* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters Mozilla's Root Store Policy] states that CAs must conduct period-of-time audits and provide updated publicly-available audit documentation no less frequently than annually..
# Updating policies and practices as issues are found/realized, communicating updates and recommendations to CAs, and tracking CA responses to communications.
#* [https://github.com/mozilla/pkipolicy/issues Issues list for Mozilla’s Root Store Policy]
#* [https://wiki.mozilla.org/CA/Communications CA Communications]
#* If a CA does not respond to Mozilla's communications within the timeframe specified in the communication or does not provide a copy of its annual audit statement within 15 months of the end of its previous annual audit period, then Mozilla may take action up to and including [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#73-removals removal of the root(s) from the program].
# When a potential certificate mis-issuance is noticed by anyone, they should report it by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance creating a bug in the CA Certificate Mis-issuance component]. More information on filing a security-sensitive bug can be found in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy.]
When a security threat or potential certificate mis-issuance arises with a CA in Mozilla's program we consider the impact and risk to the end-users to decide on the action to take. The following considerations are taken into account:
* Magnitude of the threat
** How can the threat or mis-issuance be used by a hacker to put end-users at risk?
** Has all appropriate action been taken by the CA to prevent further impact to end-users?
** What additional actions does Mozilla need to take to protect end-users from the threat or mis-issuance?
*** How will end-users be impacted by Mozilla actions?
*** Can Mozilla take a different action that will protect end-users, but confine noticeable impact to the smallest group possible?
*** Will Mozilla's actions have a worse impact on end-users than the current threat or mis-issuance?
* CA behavior
** Did the CA notice the error and take appropriate action in a timely manner?
*** Was the threat or error properly contained?
** Did the CA notice the hacker intrusion and take appropriate action in a timely manner?
*** Were the CA's defense mechanisms current and sufficient?
*** Was the intrusion appropriately contained?
** Was the CA's behavior reckless?
** Did the CA try to cover up the mistake/threat rather than follow [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy?]
Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's Root Store Policy. Statements obtained from an auditor are assumed legitimate. Audit statements provided by a CA are verified for legitimacy with the auditor. The
qualifications of any auditors not previously approved by Mozilla are reviewed before an audit statement is accepted. Auditor qualifications are reviewed using the webtrust.org website or an appropriate government website. If the auditor claims to be AICPA/CICA/CISA accredited, but the
auditor is not approved by Mozilla and not listed on a trusted website as accredited, then Mozilla will verify the auditor's qualifications with a representative of CICA or CISA, as appropriate.
= Risks to Consumers =
Possession of a mis-issued certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (shared WiFi, local network compromise) or very broad (governments). An attacker armed with a fraudulent certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. The end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) if they believe it’s coming from a trusted site.
An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network can:
* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the SSL certificate of the fake site is valid.
* Re-direct users to a fake site -- Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites.
** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.
= Potential Problems, Prevention, Response=
While CA incidents have differing levels of seriousness, there are some components which every CA should be able to avoid which are red flags for Mozilla in terms of a continued trust relationship, and which would lead to an investigation. They are:
* Deliberate violation of Mozilla or other applicable policy
* Lying or deception
Mozilla will also assess how concerned we are about an issue in part based on how the CA reacts to that issue, and previous ones. In incident response, Mozilla is looking for the following factors:
* A CA takes responsibility for their own actions.
* Incidents are taken with an appropriate level of seriousness.
* Incidents are handled with urgency.
* Root cause analysis is performed.
* Any questions posed, by anyone, are answered quickly and in detail.
* A reasonably-detailed [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report report] is made public on what happened, why, and how things have changed to make sure it won’t happen again.
The following is an enumeration of some of the different kinds of problems that may occur, and what our prevention or immediate response to those problems should be, as long as the CA is demonstrating responsibility and integrity as described above. This is not about meting out punishment, and is not intended to be punitive. Rather, when there is evidence of one of the problems below with a certificate chaining up to a CA in Mozilla's CA Certificate program, we need to take the necessary steps to keep users safe.
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] describes the steps that Mozilla takes to evaluate and respond to security concerns related to certificate operation and issuance. The following list may be used as a guideline of what to expect when certain types of issues are found, but this list is non-binding because the necessary actions and responses will vary depending on the situation.
'''Problem:''' SHA-1 certificate(s) issued
* Prevention: Don't accept SHA-1 certs. {{bug|1339662}}, in Firefox 51.
'''Problem:''' Certificate(s) issued with weak RSA key
* Prevention: Don't accept certs signed with weak RSA keys. {{bug|360126}}, in Firefox 33.
'''Problem:''' Certificate(s) issued without enough key usage info
* Prevention: Enforce key usage restrictions better. {{bug|725351}}, needs to be implemented.
'''Problem:''' CA mis-issued a small number of SSL certificates that they can enumerate
* Immediate Minimum Response: Open a CA compliance bug and request an [CA/Responding_To_An_Incident#Incident_Report incident report].
* Depending on the situation, also consider adding the certificates to OneCRL.
'''Problem:''' CA mis-issued a small number of email certificates that they can enumerate
* Immediate Minimum Response: Actively distrust that set of email certificates in Thunderbird, and push out an update to Thunderbird.
* Depending on the situation, also consider distrusting the intermediate or root certificate that the mis-issued certificates chain up to.
'''Problem:''' CA mis-issued a large number (e.g. hundreds) of end-entity certificates that they can enumerate
* Immediate Minimum Response: Open a CA compliance bug and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
* Depending on the situation, also consider adding the intermediate CA certificate(s) to OneCRL, distrusting the root certificate that the mis-issued certificates chain up to, or all of the root certificates owned by that CA.
'''Problem:''' CA mis-issued an unknown number of un-enumerated end-entity certificates
* Immediate Minimum Response: Actively distrust the intermediate and root certificates that the mis-issued certificates chain up to, and push out an update to all Mozilla products.
* Depending on the situation, also consider distrusting all of the root certificates owned by that CA.
'''Problem:''' CA mis-issued a small number of intermediate certificates that they can enumerate
* Immediate Minimum Response: Actively distrust the intermediate certificates, and push out an update to all Mozilla products.
* Depending on the situation, also consider distrusting the root certificate or all of the root certificates owned by that CA.
'''Problem:''' CA mis-issued an unknown number of un-enumerated intermediate certificates
* Immediate Minimum Response: Actively distrust the root certificate, and push out an update to all Mozilla products.
* Depending on the situation, also consider distrusting all of the root certificates owned by that CA.
'''Problem:''' CA failed to supply proper audit documentation, or audit report contains numerous and/or serious qualifications
* Immediate Minimum Response: File a CA compliance bug and request that the CA respond with remediation plans.
* Depending on the situation, also consider requiring the CA to undergo new period-of-time audits as soon as the problems have been resolved. If the same problems are included on the new audit reports, they must state the dates on which the problems were resolved.
= Ongoing Issues =
In addition to evaluating the severity of a specific incident, Mozilla considers the totality of known issues and patterns of behavior in a CAs response to those issues. When Mozilla believes that sufficient evidence is available, an Issues List may be created. Mozilla will compile the facts of known problems of a particular CA and create a wiki page listing them. Mozilla may then ask the community to consider a response to the set of issues based on the overall risk. This response typically involves distrust of the CAs currently included roots, or requiring the CA to undergo more frequent audits until the Mozilla community’s trust in the CA has been adequately restored.
'''Issues Lists'''
* https://wiki.mozilla.org/CA:PROCERT_Issues
* https://wiki.mozilla.org/CA:Symantec_Issues
* https://wiki.mozilla.org/CA:WoSign_Issues
* https://wiki.mozilla.org/CA:Visa_Issues
= Actively Distrusting a Certificate =
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] and the CA/Browser Forum's Baseline Requirements list some of the reasons why a certificate should be revoked. For the common revocations, CRL and OCSP revocation checking are sufficient. However, in extenuating circumstances, such as those listed above, Mozilla may take additional action to protect users by actively distrusting a certificate.
The steps to actively distrust a certificate are as follows.
# Report security concern
#* When a serious security concern is noticed, such as a root or intermediate certificate compromise, it should be treated as a security-sensitive bug, and the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs] should be followed.
#* As per [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs] a security concern may be reported by sending email to [mailto:security@mozilla.org security@mozilla.org] or by [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security&bug_severity=critical filing a bug.]
# Decide on course of action
#* See [[https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response | Immediate Minimum Responses]] above.
#* Depending on the situation, discussion to determine the course of action may occur in private security group email list and/or in the public mozilla.dev.security.policy forum.
#* The bug will be updated to indicate corresponding decisions.
# Measure Impact of Change
#* Check Firefox telemetry for usage data of the affected root certificate
#* Run [https://tlscanary.mozilla.org/ TLS Canary] in regression mode to determine which websites will be affected.
# Implement Code Change
#* Add the corresponding intermediate or end-entity certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].
#* If it is determined that a certificate needs to be actively distrusted in NSS, then the following will also be done.
#** Update NSS by adding a new entry to the built-in root cert list, to take away trust instead of giving trust. This is done with a separate "distrust" flag, and is called '''Active Distrust'''. Active Distrust can be done for any root, intermediate, or leaf certificate. Active Distrust does not require the entire certificate, because it may be done with a combination of the certificate Serial Number and Issuer. Note: The built-in cert list has two types of entries; cert entries and trust entries. A (dis)trust entry can be added without adding a corresponding cert entry.
#** A problem with this approach arises if the certificate to be Actively Distrusted has been cross-signed with another root certificate that is included in NSS. This could lead us to have to ask every CA in Mozilla's program if they have cross-signed with the root or intermediate certificate that is to be Actively Distrusted. If there is such cross-signing, then the change to the built-in root cert list will also have to include the Issuer/Serial number combination for the cross-signed certificate chain.
# Test
#* Manual testing: Need at least one of the bad leaf certs to make sure the distrust worked.
#* Add test to cert.sh for the ongoing test of the Active Distrust. At minimum, need the intermediate cert for this test. Preferable to also have a leaf cert, which may have been provided when the compromised cert was reported; otherwise would need to request from the CA.
# Release
#* NSS security update, or new version of NSS roots module can be released independently.
#* Depending on the timing and the urgency of the patch, the update may be done either as part of regularly scheduled [https://wiki.mozilla.org/Releases Mozilla releases,] or as a chemspill update (an off-schedule release that addresses live security vulnerabilities). Some Linux users of Firefox use their OS version of NSS, so they would have to make sure that they pick up the new version of NSS.
# Communication / Announcements
#* Announcement in mozilla.dev.security.policy
#* If the Active Distrust is the result of a security incident, then the Mozilla Security Group will assign a [http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures CVE (security incident number)] and reference the new version of NSS or root module.
#* May send an email communication to all CAs, depending on situation.
#* May post in [https://blog.mozilla.org/security/ Mozilla security blog,] depending on situation.
# Result
#* Users will get an error message when they try to browse to a website that uses (or chains up to) the Actively Distrusted certificate.
#* If a cert entry was added to the NSS built-in root cert list, then the Certificate Manager displays the Actively Distrusted certificate in the same manner as other certificates, and the trust bits may be manually turned on by users.
= Concerns =
* Certs that have been mistakenly issued with insufficient key usage can be used maliciously until we implement {{Bug|725351}}.
* The code patch to distrust a cert should only disclose the necessary information; {{Bug|826640}}.
* If the certificate to be distrusted is cross-signed by another certificate in NSS, then the Serial Number and Issuer for that certificate chain also has to be distrusted. This is error-prone, even if we ask every CA in Mozilla's program if they have cross-signed with the certificate to be distrusted.
** Possible Scenario: A cross-signing relationship is overlooked, so the malicious certificate continues to be trusted even after the security update.
** Possible Solution: {{Bug|808839}} - Ability to Actively Distrust all certs with a particular Subject.
* The Certificate Manager does not recognize the "distrust" flag, so there is no distinction in the user interface between certificates that have been Actively Distrusted in NSS and all other certificates. The distrusted certificate(s) should also be added to OneCRL, so the certificate(s) will still be distrusted even if the user manually turns on the trust bits for Actively Distrusted certificates.
** Possible Scenario: User confusion about Actively Distrusted certs listed in the Certificate Manager.
** Possible Solutions: {{Bug|470994}}, {{Bug|733716}}. For Actively Distrusted certs, remove the cert entry from the NSS built-in cert list, and only keep the (dis)trust entry.
* If the certificate to be Actively Distrusted is used by a large portion of the internet population, immediately distrusting the certificate could make many high-traffic websites no longer be reachable, giving the appearance of a large network outage, or users might take actions (such as permanently trusting the bad cert) to bypass error messages.
** Possible Scenario: A root certificate that is chained to by many high-traffic websites is compromised and has to be Actively Distrusted. This is done and an update to Firefox pushed out. Then a large number of users can no longer browse to the high-traffic websites, giving the appearance of an outage, costing those high-traffic websites loss in money, causing frustration and confusion to end users who are regular customers of those websites. Many end-users are likely to manually-override the error, permanently trusting the certificate. Then if they later accidentally browse one of the corresponding malicious websites, they will not get an error.
** Possible Solutions: {{Bug|712615}}, {{Bug|643982}}, or make an announcement that the root will be distrusted on such a date, allowing a small transition time for websites to update their SSL certs before before the Firefox chemspill update is released.
* Distrusting a certificate requires a release to the NSS root module, and users have to choose to upgrade to the new version. Firefox users are protected from distrusted certificates that are added to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].
** Possible Scenario: A user decides not to update their version of NSS, so they continue to trust the certificate in their application.
** Possible Solutions: {{Bug|647868}}
