Confirm
384
edits
Changes
Updated language to bring it current
# Carefully reviewing [[CA/Application_Process|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 reviews the CA's [https://wiki.mozilla.org/CA/Compliance_Self-Assessment Compliance Self-Assessment] andchecks 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 Required Practices], and
Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ 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 accredited (e.g. AICPA/CICA/, CPA Canada, ETSI, CISA accredited, etc., but theauditor 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 appropriatethe accrediting organization.
= 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 (public 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 TLS 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 TLS 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.
[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:''' CA mis-issued a small number of SSL TLS certificates that they can enumerate
* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
* Depending on the situation, also consider adding the certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].
* 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: Implement date-based distrust {{Bug|712615}}, a whitelist of certs certificates to remain trusted {{Bug|1151512}}, 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 TLS certificates 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].
