CA:MaintenanceAndEnforcement: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Redirect to new page)
 
(39 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{draft}}
#REDIRECT [[CA/Maintenance_and_Enforcement]]
 
= 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 checks the CA's CP/CPS documentation for
#** compliance with [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's CA Certificate Policy,]
#** compliance with [https://wiki.mozilla.org/CA: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: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 [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's CA Certificate Policy.]
# Keeping a record of current audit statements for each CA.
#* [http://tinyurl.com/MozillaBuiltInCAs Spreadsheet of included root certs and their corresponding documentation and current audit statements]
#* [http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html Mozilla's CA Certificate Maintenance Policy] states that CAs must provide an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties.
# Updating policies and practices as issues are found/realized, communicating updates and recommendations to CAs, and tracking CA responses to communications.
#* [https://wiki.mozilla.org/CA:Communications CA Communications]
#* https://wiki.mozilla.org/CA:Communications#Responses
#* If a CA does not provide updated audit statements or does not promptly respond to Mozilla's communications, then action will be taken as described in [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla's CA Certificate Enforcement Policy.]
# When a potential certificate mis-issuance is noticed by anyone, they should report it according to [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy,] and people from the [http://www.mozilla.org/projects/security/secgrouplist.html security group] work together to determine and take appropriate action, by considering the criteria listed below.
 
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?]
 
We depend on audit statements to confirm that CAs are continuing to maintain their operations in conformance with Mozilla's CA Certificate Policy. When reviewing an audit statement, if the statement is provided on the webtrust.org website or an known auditor's website or on a government certified website, then we assume the statement is legitimate, and review the statement to make sure it covers the root certs that are included in Mozilla's program. If the audit statement is provided directly by the CA, then we first check the qualifications of the auditor, and then send email directly to the auditor to confirm the authenticity of the audit statement. To check the qualifications of the auditor, if it is not someone we have previously verified, we check the [http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx webtrust.org website] or the government's website to see if the auditor is accredited. If the auditor claims to be AICPA/CICA/CISA accredited and we don't recognize them or they are not listed on a trusted website as being accredited, then we will send email to a representative of CICA or CISA, depending on the audit credentials that are being claimed.
 
= Risks to Consumers =
 
When a hacker is in possession of a mis-issued certificate, they 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.
* Sign malicious code and make it look like it came from a valid organization, such as the end-user's bank.
 
If a user visits an SSL site presenting a fraudulent certificate, there will be no obvious sign of a problem and the connection will appear to be secure.
 
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.
* Downloading malware if they believe it’s coming from a trusted site. The malware can contain malicious content or software.
 
There is currently no complete technical solution that allows browsers to detect mis-issued certificates, so we usually learn about mis-issued certificates from an inquisitive user, a CA, or another browser vendor. Once we learn about a mis-issued certificate we do a software update to add the relevant certificate(s) to a blacklist.
 
It is important to note that possession of the mis-issued certificate alone does not allow an attacker to do anything. They also need some control of 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).
 
= Potential Problems, Prevention, Response=
The following is an enumeration of some of the different kinds of problems that may occur, and what our '''minimum''' prevention and/or response to those problems should be. [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla's Enforcement Policy] describes the steps that Mozilla may take 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.
 
'''Potential Problem:''' MD5-based certs issued
* Prevention: Don't accept MD5-based certs. {{bug|650355}}, in Firefox 16.
 
 
'''Potential Problem:''' Cert issued with weak RSA key
* Prevention: Don't accept certs signed with weak RSA keys. {{bug|360126}}, needs to be implemented.
 
 
'''Potential Problem:''' Cert issued without enough key usage info
* Prevention: Enforce key usage restrictions better. {{bug|725351}}, needs to be implemented.
 
 
'''Potential Problem:''' CA mis-issues a small number of email certificates
* Proposed Response: Actively distrust that set of email certificates in Thunderbird, and push out an update to Thunderbird.
* Proposed Ramifications: ?
 
 
'''Potential Problem:''' CA mis-issues a small number of SSL certificates that they can enumerate
* Proposed Response: Actively distrust that set of SSL certificates, and push out an update to all Mozilla products.
* Proposed Ramifications: ?
 
 
'''Potential Problem:''' CA mis-issues a small number of code signing certificates
* Proposed Response: Actively distrust that set of code signing certificates, and push out an update to all Mozilla products.
* Proposed Ramifications: ?
 
 
'''Potential Problem:''' CA mis-issues a large number (e.g. hundreds) of end-entity certificates that they can enumerate
* Proposed Response: Actively distrust the intermediate certificates that the mis-issued certificates chain up to, and push out an update to all Mozilla products.
* Proposed Ramifications: Distrust the root cert?
 
 
'''Potential Problem:''' CA mis-issued an unknown number of un-enumerated end-entity certificates
* Response: Actively distrust the intermediate and root certificates, and push out an update to all Mozilla products.
* Ramifications: Distrust the root cert, possibly all of the CA's root certs.
 
 
'''Potential Problem:''' CA mis-issued an intermediate certificate
* Response: Actively distrust the intermediate certificate, and push out an update to all Mozilla products.
* Proposed Ramifications: Consider distrusting the root cert, possibly all of the CA's root certs.
 
 
'''Potential Problem:''' CA mis-issued more than one intermediate certificate
* Response: Actively distrust the intermediate and root certificate, and push out an update to all Mozilla products.
* Proposed Ramifications: Distrust the root cert, possibly all of the CA's root certs.
 
= Actively Distrusting a Certificate =
 
The steps to distrust a root certificate are as follows.
# Report security concern
#* When a serious security concern is noticed, such as a major root 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?alias=&product=Core&component=Security&bug_severity=critical filing a bug.]
# Decide on course of action
#* Depending on the situation, discussion to determine the course of action may occur in security-group@mozilla.com and/or in mozilla.dev.security.group.
#* The bug will be updated to indicate corresponding decisions.
# Implement Code Change
#* If it is determined that a certificate needs to be actively distrusted, then the following will be done.
#** Update NSS by adding a new entry to the built-in root cert list, which takes 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. Currently Active Distrust is done by using a combination of the certificate Serial Number and Issuer (the entire certificate is not needed).
#** 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.
#* Firefox chemspill update; e.g. new version of Firefox with the NSS update. 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
#* Posting announcement in mozilla.dev.security.policy
#* If the Active Distrust is the result of a security incident, then Redhat Security Response team triggers creation of a [http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures CVE (security incident number)] and references the new version of NSS or root module.
#* May send an email communication to all CAs, depending on situation.
#* May post in [http://blog.mozilla.org/security/ Mozilla security blog,] depending on situation.
# Result
#* When a certificate is distrusted, users will get an error message when they try to browse to a website that uses (or chains up to) the certificate.
#* 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 with weak RSA keys or insufficient key usage can be used maliciously until we implement {{Bug|360126}} and {{Bug|725351}}.
* 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.
* 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 Solution: {{Bug|712615}}, {{Bug|643982}}
* The Certificate Manager does not recognize the "distrust" flag, so there is no distinction in the user interface between Actively Distrusted certificates and all other certificates. Additionally, users can manually turn on the trust bits for Actively Distrusted certificates.
** Possible Scenario: A user gets an error message that a website they browsed to is untrusted. They open the Certificate Manager and turn on the trust bits for an Actively Distrusted cert. This change is permanent until the user manually restores the default root settings or turns off the trust bits for that cert. So at some later date the user could accidentally browse to the corresponding malicious website and the site will appear to be trusted.
** Possible Solution: {{Bug|470994}}, {{Bug|733716}}
* Distrusting a certificate requires a release to the NSS root module and to Firefox, and users have to choose to upgrade to the new version.
** Possible Scenario: An end user decides not to update their version of Firefox, so they continue to trust the certificate, somehow browse to the corresponding malicious website, and the website is shown as trusted.
** Possible Solution: {{Bug|647868}} or https://wiki.mozilla.org/Security/Features/Cert_Blocklist_via_Update_Ping

Latest revision as of 20:15, 24 September 2018

Redirect to:

Retrieved from "https://wiki.allizom.org/index.php?title=CA:MaintenanceAndEnforcement&oldid=1201489"