Confirm, administrator
5,526
edits
Changes
Added more background information
== Revocation Is Important ==
Support for revoking certificates is important, because otherwise stolen and misissued certificates can be misused until they expire. History, from DigiNotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Mozilla has and will continue to invest in certificate revocation checking.
Recent changes to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements (BRs)] and [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] have reduced the risks associated with exposure of the private key for each TLS certificate:
* Subscriber Certificates issued on or after 1 September 2020 … MUST NOT have a Validity Period greater than 398 days.
* Effective 2021‐10‐01, for validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.
Under these provisions, the maximum validity period and maximum re-use of domain validation for TLS certificates roughly corresponds to the typical minimum period of time for owning a domain name; i.e. one year. Assuming that most website operators correctly protect the private keys for their TLS certificates for the duration of the time that they own the domain name, these provisions reduce the risk of potential exposure of the private key of each TLS certificate that is revoked, replaced, or no longer needed by the original certificate subscriber.
We still need to take into account situations in which the private key of a TLS certificate is obtained by an attacker or otherwise compromised. This can happen at any time during the certificate’s validity period if the website’s servers become compromised.
Possession of a compromised private key for a TLS 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 (DNS servers, governments). An attacker armed with the private key of a TLS certificate and an ability to control their victim’s network could impersonate the website corresponding to the compromised certificate in a way that would be undetectable to most users. Then even vigilant end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) because they believe it is coming from a trusted site.
An attacker armed with a compromised private key for a 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 TLS certificate of the fake site is valid.
* Re-direct users to a fake site -- Users on a compromised network could be directed to a website using a fraudulent certificate and mistake it for the legitimate site.
** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing). Many users might not notice this and end up logging into an attacker’s website.
== Challenges ==
