136
edits
CA/Maintenance and Enforcement: Difference between revisions
Jump to navigation
Jump to search
CA/Maintenance and Enforcement (view source)
Revision as of 20:04, 24 September 2018
, 24 September 2018→Concerns: Update scenarios with new info
m (minor updates) |
(→Concerns: Update scenarios with new info) |
||
| Line 148: | Line 148: | ||
* 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. | * 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 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| | ** Possible Solutions: Implement date-based distrust {{Bug|712615}}, a whitelist of certs 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 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]. | * 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 Scenario: A user decides not to update their version of NSS, so they continue to trust the certificate in their application. | ||
** Possible Solutions: {{Bug| | ** Possible Solutions: OneCRL {{Bug|1130757}} | ||