Certificate Transparency is an open framework for monitoring and auditing the certificates issued by Certificate Authorities in near real-time. By requiring a CA to log all certificates they generate, site owners can quickly identify mis-issued certificates and it becomes much easier to detect a rogue CA.
Certificate Transparency
The CT project is a Google endeavour that is completely open and you can find more info on their site or the RFC. The basic idea behind the project is greater transparency around the issuance of x.509 certificates. With this greater transparency we can better achieve the end goal of protecting users. Site owners can detect maliciously or accidentally mis-issued certificates that may be abused to impersonate them and rogue CAs can be identified more easily and reliably. I'm not going to dive into the technical details in this article, it's intended more to raise awareness of CT, the requirements it places on us as site owners/operators and the basic principles behind it. Google announced in October 2016 that all certificates issued in October 2017 and beyond would need to be logged in CT or Chrome would not trust them. This means that if you operate a website that uses HTTPS you at least need to make sure your certificates will comply with Chrome's CT policy before October 2017 April 2018 (update) if you want your site to work in Chrome.
Signed Certificate Timestamp
Certificates will typically be submitted to CT logs by the CA that issued them but it is also possible for a site owner to submit their own certificates to a log too. An SCT is the response from a Certificate Log when you submit a certificate which is essentially a promise that the certificate will be added to the log in a given amount of time. It's this SCT that we have to deliver to clients when they make a TLS connection to our site and there are 3 ways that we can do this.
x.509v3 Extension
The preferred method to deliver an SCT for a site operator is via an X.509v3 extension. This means that your CA will embed the SCT in your certificate before they sign it and issue it to you so absolutely no work or setup is required on your part. The CA will construct your certificate and prior to the last step of signing it they will submit it to the CT log as a precertificate. The log will respond with the SCT for the precertificate, the CA will embed that in the certificate and then sign it, ready for issuing to you.
TLS Extension
The SCT can also be delivered via a TLS extension from the host to the connecting client. This takes place during the TLS handshake using an extension called signed_certificate_timestamp but does require the host to update their server and configure it to deliver the SCT. The benefit here is for the CA, who doesn't have to change how they issue certificates , but waiting for reliable server implementations of the SCT TLS extension might not be great for site operators.
OCSP Stapling
I'm a fan of OCSP Stapling and it's usually used to deliver revocation information about our certificate but it can also be used to deliver the SCT from the CA to the site operator. There's a benefit for the CA again as they don't have to change their issuance process, they simply sign and issue the certificate as normal and make the SCT available via OCSP. Again though, this is a problem for us as our server needs to be able to reliably OCSP Staple and include the SCT to the client during the handshake.
The ideal scenario
The above is a very high level description of the 3 methods available to us to deliver an SCT but it should still be pretty clear that the x.509v3 Extension is the most preferred option for us as the site operator. It will be interesting to see how CAs progress and which options they support as this requirement will be coming into force a little over 7 months from the time of writing. The problem with the TLS Extension and OCSP Stapling is that they require the server operator to patch/update/configure something quite technical. For that reason alone I don't think it's the best choice given the time frames involved. Pushing the responsibility over to the CA seems like the best choice but this does come with quite a burden for them too. There is the technical implementation of submitting the precertificate to the log, yes, but there are other concerns too. Let's take Let's Encrypt as a great example of what I mean.
Slowing down issuance
Let's Encrypt have been going a little over a year now and in that time they've issued millions of certificates, tens of millions. Right now they have over 28 million active certificates alone.
That's a lot of certificates, but more importantly they're being issued at a very fast rate. For the CA to embed the SCT in the certificate, they have to send the precertificate to the log and wait for the SCT to be returned before they sign. This is the problem, it's a synchronous operation. I'm sure many other CAs will suffer the same problem but none have public data for me to refer to, but a CA waiting around for a log to respond with an SCT is a problem, especially in automated issuance scenarios. Not only that, but it has to be submitted to two logs, one operated by Google and one not operated by Google, at a minimum. This means that the logs now become a point of failure in the issuance process and at best will slow things down, though apparently it shouldn't be too much. Not to mention there isn't really a financial incentive to operate a log and does any log operator out there want to take on the burden of accepting Let's Encrypt and their massive requirements, let alone other major CAs? It's a problem that can be solved and it will be interesting to see how it turns out.
Monitoring CT Logs
The whole point of CT is to give us more transparency and we can now monitor CT logs to see if any certificates are issued for our domains. The site I've been using for a while, https://crt.sh/, is simple but highly effective and you can search for any certificates issued for a given domain name. Here's a search for all certificates for my domain.
You can see my regular issuance from Let's Encrypt and the Comodo certs are because I use Cloudflare for my DNS so they regularly obtain a certificate with my domain in the SAN. Crt.sh is great for searching manually but there isn't a notification option. Ideally we don't want to have to search for certificates that contain our domain, we want to be notified when they are issued. For this I'm actually using two services right now offered by sslmate, with their CertSpotter tool, and Facebook, with their Certificate Transparency Monitoring. CertSpotter is free to use for up to five domains and it doesn't seem that the Facebook tool has a limit. They're both free to use if you have an account and all you have to do is type in the domain you want notifications for and subscribe. You will then get notifications via email each time a certificate is issued. Here are two I got recently from Facebook, one was the renewal of the wildcard certificate for report-uri.io from AlphaSSL and the other was for scotthelme.co.uk from Let's Encrypt.
Now I've got monitoring setup if I see a certificate issued by WoSign or StartCom (or anyone for that matter) then I can take immediate action to have it revoked. Without CT you wouldn't even be aware that this certificate had been issued and probably would never become aware of it either.
Problems with CT
There hasn't really been much resistance to CT as a mechanism, just around the requirements to implement it. I've already covered the implementation side and I'm sure we can see there is possibly an overhead there depending on how we do things, but what about CT in general? One of the first things that stands out is the availability and scalability of logs. As the size of the encrypted web continues to grow and certificate lifetimes become shorter, a bigger burden is going to be placed on log operators. This isn't really a problem with CT, just an infrastructure concern that needs to be overcome. I've also covered the main burden on the CA above which is obtaining the SCT with the precertificate prior to signing. Again, this is just an additional step in the workflow that the CA needs to factor in. The only real 'problem' that I can see the industry concerned with in regards to CT is disclosure of information. With all certificates going into CT logs, organisations may be disclosing information that they don't want to. Let's say Scott Helme Industries is starting a new super secret project and we need a certificate, if we get one for secretproject.scotthelme.co.uk then our competitors may be able to glean information about what we're doing. This can of course work in a whole bunch of different ways, but with the transparency of CT comes the possibility that it may disclose information that people or organisations don't want to disclose. The details in a certificate may link a company to a domain name or it could disclose subdomains used internally that they don't want to disclose. There was some discussion of this in a recent CA/Browser Forum meeting for which the minutes are available (link) but it seems like some redaction of the meta data in certificates, where required, is the simple solution to this problem. Beyond this, I can't really see any real resistance to CT.
The first step
CT isn't the solution to the problem of revocation, it's just the first step in the right direction. We could have the best revocation mechanisms in the world that were fully reliable, but if you don't know that there's a rogue certificate out there that you need to take action over then what use are they? Bringing this level of transparency to the ecosystem will be a huge victory and make Certificate Authorities more auditable and accountable. Given the scope of their power, I look forward to it.
Useful links
The Chromium Certificate Transparency Project: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/certificate-transparency
Chrome requirements for a certificate to be 'CT Qualified': https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy/CTPolicyMay2016edition.pdf
The Certificate Transparency project: https://www.certificate-transparency.org/
The CT policy Google Group: https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy