Let's Encrypt, a leading issuer of SSL/TLS certificates, is preparing to take a big step forward by adding support for Certificate Transparency. This capability, now merged into Let's Encrypt's
Boulder CA suite, will resolve a long-standing feature request by embedding Signed Certificate Timestamps (SCTs) into newly minted certificates. Because the SCT will be attached directly to the certificate, no additional server modules or configuration will be needed by site administrators.
Certificate Transparency support will allow websites using Let's Encrypt certificates to implement the Expect-CT HTTP header. This header provides additional security by instructing web browsers to verify the certificates they receive against public certificate transparency logs. Forged or otherwise malicious certificates are often absent from these logs, and will never contain the correct SCT, making them easier to detect when a site uses
The feature isn't yet live, but the Let's Encrypt project has announced Q1 2018 as the release target, and the latest announcement suggests a rollout by the end of March.
What Certificate Transparency does
In a perfect world, every time you connect to a website (or other service) over TLS, you'd be able to trust the certificate presented by the remote host as long as it's issued by a valid Certificate Authority that you also trust. But digital trust isn't perfect. Private signing keys sometimes get compromised, and CAs occasionally exhibit unscrupulous behavior, resulting in forged or mis-issued certificates that look valid but are controlled by a malicious actor. These certs can be used to intercept traffic, inject resources, or perform other man-in-the-middle style attacks.
Certificate Transparency (RFC6962) helps mitigate this problem by introducing additional verification into the chain of trust. The foundation lies in certificate logs, which are implemented as immutable, cryptographically signed ledgers that can be viewed and audited by the public. (If you're into buzzwords, you can think of a certificate log as a blockchain for SSL certs.) Public certificate logs are currently operated by Google, Cloudflare, DigiCert, Certly, Izenpe, WoSign, Venafi, CNNIC, StartCom, and Comodo, with other services like crt.sh providing an index to their data.
When a participating CA like Let's Encrypt mints a new certificate, they submit it to one or more certificate logs, creating a permanent visible record of its issuance. The certificate log, in turn, responds to the CA with a signed certificate timestamp (SCT) corresponding to the log entry. These logs and signatures are routinely monitored by domain owners, security researchers, and intellectual property firms. The idea is that all of this auditing means bogus certificates will be spotted early and can be quickly revoked, minimizing the fallout from counterfeits.
Automated certificate verification through Expect-CT
Certificate log monitoring only solves one aspect of the forgery threat model, because only certificates that are proactively submitted to the public logs can be inspected. An attacker who creates a malicious certificate isn't likely to publish it and tip their hand. Such certificates are often narrowly deployed to target specific individuals or groups, keeping them hidden from organizations that perform routine auditing. A system is also needed for individual end users to detect problem certificates, and this piece of the puzzle can be addressed with the
Expect-CT HTTP header.
In 2017, engineers at Google proposed a new HTTP header called
Expect-CT (draft specification). By implementing thi...