Certificate Transparency Means What, Again?

Brian King //

ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.

News from Google this week says that Chrome will start enforcing Certificate Transparency a year from now.

https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/78N3SMcqUGw

This means that when Chrome contacts a website, if it finds that the certificate does not adhere to Transparency requirements, Chrome won’t load the page. They’re announcing it now so interested parties can comment and possibly influence the details of how that will work in practice.

So what is Certificate Transparency, and why should you care?

Certificate Transparency is a way to detect Bad Certificates. A Bad Certificate is one that was issued incorrectly in some way but is not a forgery. Our existing public-key cryptography and trusted CA stores in your browser already detect forgeries, as well as signatures that can’t be validated. That’s what triggers the familiar certificate warning in your web browser.

In this other sense, a Bad Certificate is one that was issued without the CA’s valid assent, or without having properly verified that the requestor had authority to act on behalf of the domain name in question. Root causes for these kinds of problems include forged identity documents, hijacked verification steps, compromised root certificates, malicious insiders, and rouge or misbehaving certificate authorities.

Certificate Transparency is accomplished through the use of independent, cryptographically-verifiable, append-only logs that provide information about certificates. Anyone can submit a certificate to these logs, and anyone can query them to see if a particular certificate is in there. There will be lots of these log servers, independently operated. Certificate Authorities will likely run their own, and auto-submit their certificates as they issue them, but anyone can run one. Google’s announcement means that Chrome will complain (in some fashion) if it gets a certificate from a website and cannot find that certificate properly registered in one of these logs.

Monitoring services will keep an eye on these log servers. These will look for certificates that are “wrong” in some way. Maybe a server certificate that has the CA bit set, and so can sign other certificates. Maybe a certificate is signed by a legitimate CA’s root certificate but was not actually issued by that CA. This is one reason a CA would run their own log server: if they see a certificate signed with their keys appear in someone else’s log server but not their own, it’s time to hit the panic button – someone has misused their signing keys.

Auditing services will make sure that the log is functioning properly at an administrative level. They will verify that the log hasn’t been tampered with, for example, by verifying the cryptographic signatures. These will also lookup individual certificates to see if they exist in a given log. Your browser will have a built-in, limited purpose auditor.

It seems likely that all three of these roles will be carried out by certificate authorities, browser vendors, academics, and researchers.

This is a giant leap towards independent verification of SSL/TLS security and provides a strong supplement to the blind trust we all implicitly grant to the long, long list of certificate authorities built into our browsers.

If you operate a web site or any service secured by certificates, go learn more: https://www.certificate-transparency.org/

This all came to my attention in the Feisty Duck newsletter that Ivan Ristić publishes – a fantastic place to keep up with SSL/TLS issues.