136
edits
Changes
→Concerns: Update scenarios with new info
* 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 to remain trusted {{Bug|6439821151512}}, 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: OneCRL {{Bug|6478681130757}}
