Certificate Transparency

From Justapedia, unleashing the power of collective wisdom
Jump to navigation Jump to search

Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates.[1] The standard creates a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates.[2] Version 2.0 of the Certificate Transparency mechanism, the latest, is described in the experimental RFC 9162, which obsoletes the earlier version 1.0 described in RFC 6962.

Technical overview

The certificate transparency system consists of a system of append-only certificate logs. Logs are operated by many group of parties, including browser vendors and certificate authorities.[3] Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log. Each entry in a log references the hash of a previous one, forming a Merkle tree. The signed tree head (STH) references the current root of the Merkle tree.

Mandatory certificate transparency

Some browsers require TLS certificates to have proof of being logged with certificate transparency,[5][6] either through SCTs embedded into the certificate, an extension during the TLS handshake, or through OCSP:

Browser Current SCT requirements Current OCSP/TLS extension requirements
Chrome/Chromium
  • 1 current SCT
  • 1 SCT from a once-approved Google log
  • 1 SCT from a once-approved non-Google log
  • Duration > 15 months: SCTs from 3 logs
  • Duration > 27 months: SCTs from 4 logs
  • Duration > 39 months: SCTs from 5 logs[7]
  • 1 SCT from a current Google log
  • 1 SCT from a current non-Google log
Firefox None[8] None
Safari
  • One SCT from a currently approved log
  • Duration < 180 days: 2 SCTs from once-approved logs
  • Duration > 180 days: 3 SCTs from once-approved logs[9]
 Two SCTs from currently approved logs

Log sharding

Due to the large quantities of certificates issued with the Web PKI, certificate transparency logs can grow to contain many certificates. This large quantity of certificates can cause strain on logs. Temporal sharding is a method to reduce the strain on logs by sharding a log into multiple logs, and having each shard only accept precertificates/certificates with an expiration date in a particular time period (usually a calendar year).[10][11][12] Cloudflare's Nimbus series of logs was the first to use temporal sharding.

Background

Advantages

One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked. An issued certificate not logged using Certificate Transparency may never be spotted at all. Certificate Transparency makes it possible for the domain owner (and anyone interested) to get in knowledge of any certificate issued for a domain.

Certificate Transparency logs

Certificate Transparency depends on verifiable Certificate Transparency logs. A log appends new certificates to an ever-growing Merkle hash tree.[1]: Section 3  To be seen as behaving correctly, a log must:

  • Verify that each submitted certificate or precertificate has a valid signature chain leading back to a trusted root certificate authority certificate.
  • Refuse to publish certificates without this valid signature chain.
  • Store the entire verification chain from the newly accepted certificate back to the root certificate.
  • Present this chain for auditing upon request.

A log may accept certificates that are not yet fully valid and certificates that have expired.

Certificate Transparency monitors

Monitors act as clients to the log servers. Monitors check logs to make sure they are behaving correctly. An inconsistency is used to prove that a log has not behaved correctly, and the signatures on the log's data structure (the Merkle tree) prevent the log from denying that misbehavior.

Certificate Transparency auditors

Auditors also act as clients to the log servers. Certificate Transparency auditors use partial information about a log to verify the log against other partial information they have.[1]: Section 5.4 

Certificate Transparency log programs

Apple[13] and Google[10] have separate log programs with distinct policies and lists of trusted logs.

Root stores of Certificate Transparency logs

Certificate Transparency logs maintain their own root stores and only accept certificates that chain back to the trusted roots.[1] A number of misbehaving logs have been publishing inconsistent root stores in the past.[14]

History

An example of Certificate Transparency entry on Firefox 89

In 2011, a reseller of the certificate authority Comodo was attacked and the certificate authority DigiNotar was compromised,[15] demonstrating existing flaws in the certificate authority ecosystem and prompting work on various mechanisms to prevent or monitor unauthorized certificate issuance. Google employees Ben Laurie, Adam Langley and Emilia Kasper began work on an open source framework for detecting mis-issued certificates the same year. In 2012, they submitted the first draft of the standard to IETF under the code-name "Sunlight".[citation needed]

In March 2013, Google launched its first certificate transparency log.[16] In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency.[17]

In 2015, Google Chrome began requiring Certificate Transparency for newly issued Extended Validation Certificates.[18][19] It began requiring Certificate Transparency for all certificates newly issued by Symantec from June 1, 2016, after they were found to have issued 187 certificates without the domain owners' knowledge.[20][21] Since April 2018, this requirement has been extended to all certificates.[6]

On March 23, 2018, Cloudflare announced its own CT log named Nimbus.[22]

In March 2018, "Certificate Transparency Version 2.0" draft was published.[23]

In May, 2019, certificate authority Let's Encrypt launched its own CT log called Oak. Since February 2020, it is included in approved log lists and is usable by all publicly-trusted certificate authorities.[24]

In December 2021, IETF RFC 9162 “Certificate Transparency Version 2.0” was published. CTv2.0 revises and obsoletes the CTv1.0 protocol, drawing insights from CTv1.0's deployments and feed-backs from the community. Version 2.0 includes major changes to the required structure of the log certificate, as well as support for Ed25519 as a signature algorithm of SCTs and support for including certificate inclusion proofs along the SCT.

In February 2022, Google published an update to their CT policy,[25] which removes the requirement for certificates to include a SCT from their own CT log service, matching all the requirements for certificates to those previously published by Apple.[26]

Signature Algorithms

In Certificate Transparency Version 1.0, a log must use NIST P-256 curve, or RSA signatures (using a key of at least 2048 bits).[1]:section 2.1.4

In the updated Certificate Transparency Version 2.0 standard,[27] the allowed algorithms are NIST P-256, Deterministic ECDSA, or Ed25519.

Tools for inspecting CT logs

References

  1. ^ a b c d e Laurie, Ben; Langley, Adam; Kasper, Emilia (June 2013). Certificate Transparency. IETF. doi:10.17487/RFC6962. ISSN 2070-1721. RFC 6962.
  2. ^ Solomon, Ben (8 August 2019). "Introducing Certificate Transparency Monitoring". Cloudflare. Archived from the original on 8 August 2019. Retrieved 9 August 2019. Ah, Certificate Transparency (CT). CT solves the problem I just described by making all certificates public and easy to audit. When CAs issue certificates, they must submit certificates to at least two “public logs.” This means that collectively, the logs carry important data about all trusted certificates on the Internet.
  3. ^ a b Scheitle, Quirin; Gasser, Oliver; Nolte, Theodor; Amann, Johanna; Brent, Lexi; Carle, Georg; Holz, Ralph; Schmidt, Thomas C.; Wählisch, Matthias (2018-10-31). "The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem". Proceedings of the Internet Measurement Conference 2018. Boston MA USA: ACM: 343–349. doi:10.1145/3278532.3278562. ISBN 978-1-4503-5619-0.
  4. ^ "How CT Works : Certificate Transparency". certificate.transparency.dev. Retrieved 2022-02-25.
  5. ^ Call, Ashley (2015-06-03). "Certificate Transparency: FAQs | DigiCert Blog". DigiCert. Retrieved 2021-04-13.
  6. ^ a b O'Brien, Devon (7 February 2018). "Certificate Transparency Enforcement in Google Chrome". Google Groups. Retrieved 18 December 2019.
  7. ^ "Chrome Certificate Transparency Policy". CertificateTransparency. Retrieved 2022-02-26.
  8. ^ "Certificate Transparency - Web security | MDN". developer.mozilla.org. Retrieved 2022-02-26.
  9. ^ "Apple's Certificate Transparency policy". Apple Support. Retrieved 2022-02-26.
  10. ^ a b "Chrome CT Log Policy". googlechrome.github.io. Retrieved 2021-10-14.
  11. ^ Tomescu, Alin; Bhupatiraju, Vivek; Papadopoulos, Dimitrios; Papamanthou, Charalampos; Triandopoulos, Nikos; Devadas, Srinivas (2019-11-06). "Transparency Logs via Append-Only Authenticated Dictionaries". Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. London United Kingdom: ACM: 1299–1316. doi:10.1145/3319535.3345652. ISBN 978-1-4503-6747-9.
  12. ^ "Scaling CT Logs: Temporal Sharding | DigiCert.com". www.digicert.com. Retrieved 2022-02-26.
  13. ^ "Apple's Certificate Transparency log program". apple.com. Retrieved 2021-10-14.
  14. ^ Korzhitskii, Nikita; Carlsson, Niklas. Characterizing the root landscape of Certificate Transparency logs. In proceedings of 2020 IFIP Networking Conference (Networking).{{cite book}}: CS1 maint: url-status (link)
  15. ^ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Retrieved 2018-02-10.
  16. ^ "Known Logs - Certificate Transparency". certificate-transparency.org. Retrieved 2015-12-31.
  17. ^ "DigiCert Announces Certificate Transparency Support". Dark Reading. 2013-09-24. Retrieved 2018-10-31.
  18. ^ Woodfield, Meggie (December 5, 2014). "Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome". DigiCert Blog. DigiCert.
  19. ^ Laurie, Ben (February 4, 2014). "Updated Certificate Transparency + Extended Validation plan". public@cabforum.org (Mailing list). Archived from the original on 2014-03-30.
  20. ^ "Symantec Certificate Transparency (CT) for certificates issued before June 1, 2016". Symantec Knowledge Center. Symantec. June 9, 2016. Archived from the original on October 5, 2016. Retrieved September 22, 2016.
  21. ^ Sleevi, Ryan (October 28, 2015). "Sustaining Digital Certificate Security". Google Security Blog.
  22. ^ Sullivan, Nick (23 March 2018). "Introducing Certificate Transparency and Nimbus". cloudflare.com. Archived from the original on 23 March 2018. Retrieved 9 August 2019.
  23. ^ Laurie, B. (2018-03-05). "Certificate Transparency Version 2.0". tools.ietf.org. Retrieved 2021-04-13.
  24. ^ "Introducing Oak, a Free and Open Certificate Transparency Log - Let's Encrypt". letsencrypt.org. Retrieved 2021-04-13.
  25. ^ "Google CT Policy Update". Google Groups. Retrieved 2022-02-14.
  26. ^ "Apple's Certificate Transparency Policy". support.apple.com. Retrieved 2022-02-14.
  27. ^ "RFC 9162 - Certificate Transparency Version 2.0". datatracker.ietf.org. Retrieved 2022-02-14.

External links

Retrieved from "https://justapedia.org/index.php?title=Certificate_Transparency&oldid=1108909791"