SecurityEngineering/Certificate Transparency: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "This page describes the current draft plan for implementing [http://www.certificate-transparency.org/ Certificate Transparency] in Gecko/Firefox. === The Plan === First we ne...")
 
(rewrite page to reflect current state of CT in Firefox)
Line 1: Line 1:
This page describes the current draft plan for implementing [http://www.certificate-transparency.org/ Certificate Transparency] in Gecko/Firefox.
[https://certificate.transparency.dev/ Certificate Transparency] (CT) is a system that works to ensure that TLS web server certificates are verifiably publicly disclosed before they can be used, which allows for certificate misissuance to be detected.


=== The Plan ===
== Certificate Transparency Support in Firefox ==
First we need to implement the ability to verify and interpret certificate transparency data (i.e. Signed Certificate Timestamps, or SCTs). Currently there are three ways to convey an SCT:
The security engineering team is actively working to implement Certificate Transparency in Firefox. As of version 133, it is enforced in Nightly by default, meaning that every TLS web server certificate must be accompanied by sufficient certificate transparency information for Nightly to connect without showing an error page.


* Via an x509 extension in the end-entity certificate
Certificate transparency is controlled by the preference ''security.pki.certificate_transparency.mode''. A value of '''0''' disables CT entirely. '''1''' enables CT, but does not enforce it, allowing Firefox to collect telemetry on the implementation and the ecosystem. Setting this preference to '''2''' causes Firefox to enforce CT for certificates issued by roots in [[CA|Mozilla's Root CA Program]].
* Via a TLS extension
* Via an extension in a stapled OCSP response


As of this writing, Google, DigiCert, Certly, and Izenpe are running CT logs that may produce these SCTs (see [https://www.chromium.org/Home/chromium-security/certificate-transparency this page] for an updated list and more details). We should be able to verify data from any of these logs and be able to distinguish their provenance.
=== Known CT Logs ===
The list of known CT logs is [https://hg.mozilla.org/mozilla-central/file/tip/security/ct/CTKnownLogs.h#l44 compiled into] Firefox. This list is derived from [https://www.gstatic.com/ct/log_list/v3/log_list.json Chromium's list] and is automatically updated each week in prerelease versions of Firefox.


Next we should gather telemetry on:
Each log in the source list is in one of a number of states. Firefox disregards logs that are '''Pending''' or '''Rejected'''. Firefox considers logs that are '''Qualified''', '''Usable''', or '''ReadOnly''' to be '''Admissible'''. Firefox makes notes of logs that are '''Retired''', along with the retirement time.
* How often which SCT delivery vector is used
* Which logs are being used
* Any kind of relationship between certificate validity period and number of SCTs per connection
* If we applied a policy of requiring some number of SCTs to show the EV indicator, how often would we decline to do so for a certificate that otherwise validates as EV


If the data looks good, we can create and enforce a policy. For reference, Chrome's policy documentation can be found [http://www.certificate-transparency.org/ev-ct-plan here].
This information has a 10 week expiration time. That is, if 10 weeks have passed since the information has been updated (typically by updating Firefox itself), the implementation will no longer enforce certificate transparency.


Additionally, and ideally before we enforce a policy, some design/UX work should go into displaying to the user information regarding if a site has presented SCTs for their certificate.
=== CT Policy ===
Certificate transparency information can be delivered either as signed certificate timestamps (SCTs) embedded in the certificate itself or as SCTs stapled alongside the certificate (via the TLS handshake or in an OCSP response). For a connection to succeed, sufficient certificate transparency information must be provided using either of these methods.


Concurrently, we should explore running a CT log at Mozilla.
For embedded SCTs, "sufficient" means at least N SCTs from distinct logs that were '''Admissible''' or '''Retired''' at the time of verification, where N is 2 for certificates with a lifetime of 180 days or less, and 3 otherwise. At least 1 of those SCTs must be from a log that was Admissible at the time of verification. Among those SCTs, at least 2 must be from distinct log operators.
 
For SCTs delivered via the TLS handshake or an OCSP response, "sufficient" means at least 2 SCTs from distinct log operators that were '''Admissible''' at the time of verification.
 
=== CT Log Policy ===
TK

Revision as of 20:43, 31 October 2024

Certificate Transparency (CT) is a system that works to ensure that TLS web server certificates are verifiably publicly disclosed before they can be used, which allows for certificate misissuance to be detected.

Certificate Transparency Support in Firefox

The security engineering team is actively working to implement Certificate Transparency in Firefox. As of version 133, it is enforced in Nightly by default, meaning that every TLS web server certificate must be accompanied by sufficient certificate transparency information for Nightly to connect without showing an error page.

Certificate transparency is controlled by the preference security.pki.certificate_transparency.mode. A value of 0 disables CT entirely. 1 enables CT, but does not enforce it, allowing Firefox to collect telemetry on the implementation and the ecosystem. Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.

Known CT Logs

The list of known CT logs is compiled into Firefox. This list is derived from Chromium's list and is automatically updated each week in prerelease versions of Firefox.

Each log in the source list is in one of a number of states. Firefox disregards logs that are Pending or Rejected. Firefox considers logs that are Qualified, Usable, or ReadOnly to be Admissible. Firefox makes notes of logs that are Retired, along with the retirement time.

This information has a 10 week expiration time. That is, if 10 weeks have passed since the information has been updated (typically by updating Firefox itself), the implementation will no longer enforce certificate transparency.

CT Policy

Certificate transparency information can be delivered either as signed certificate timestamps (SCTs) embedded in the certificate itself or as SCTs stapled alongside the certificate (via the TLS handshake or in an OCSP response). For a connection to succeed, sufficient certificate transparency information must be provided using either of these methods.

For embedded SCTs, "sufficient" means at least N SCTs from distinct logs that were Admissible or Retired at the time of verification, where N is 2 for certificates with a lifetime of 180 days or less, and 3 otherwise. At least 1 of those SCTs must be from a log that was Admissible at the time of verification. Among those SCTs, at least 2 must be from distinct log operators.

For SCTs delivered via the TLS handshake or an OCSP response, "sufficient" means at least 2 SCTs from distinct log operators that were Admissible at the time of verification.

CT Log Policy

TK

Retrieved from "https://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Transparency&oldid=1252289"