Certificate Transparency

Certificate Transparency

I've just been reading about this new Google initiative called certificate transparency here and I read the RFC. The goal is to avoid or detect the issuance of bogus certificates by a trusted CA. The idea is that all issued SSL server certificates are published in a verifiable log to allow independent organisations to verify them.

I found a number of areas I don't quite understand or that I think might be problematic. This post describes my understanding and the problems I have with the initiative.

Why do this?

Back in 2011 a Norwegian CA (DigiNotar) published a certificate for the Google domain. The certificate was purportedly requested by the Iranian government to implement a Man-In-The-Middle attack to enable them to eavesdrop on Gmail and other Google traffic leaving Iran. Essentially the way this would work is that the government (or an ISP) implement a proxy and when someone accesses the Google domain, the proxy would re-direct the traffic to a MITM server. That server sends the client the bogus Google certificate which the client successfully validates and then the server passes the traffic onto the real Google domain while stashing a copy of anything interesting.

The reason this happened is because DigiNotar is a trusted CA. That is Diginotar went through the expensive and arduous process of being certified as a trusted root and having its root certificate then added to the trusted root certificate store of every browser, JVM etc. In addition it issued (either inadvertently or otherwise) a certificate for the Google domain to someone other than Google.

Not New

Actually this practice is not new. In a Windows Domain (Enterprise) environment, you can place a certificate in the Services/Public Key Service/Certification Authorities container and each computer in the domain will trust that certificate. Some web filter implementations (like the ones used by schools to prevent kids accessing porn etc) will publish a bogus root certificate and will then create bogus domain certificate signed by the published root for every URL any user accesses. Using this the web filter can implement a MITM and read SSL traffic going through the web filter box.

The web filter trick is quite evil in terms of its effects on the privacy of your staff. Now you know why Windows warns you when you add a certificate to the trusted root store...

Certificate Transparency

Google's idea is that CAs will send every SSL server certificate to one or more public log servers for publication. The log server adds the certificate to the log and signs the log entry (Signed certificate timestamp). The log is constructed so that the entire log is verifiable (i.e. you can verify that no entry has been deleted and that each entry hasn't been tampered with).

SSL Servers can provide the Signed Certificate Timestamp (SCT) to clients when they authenticate. Alternaticely CAs can log the certificate as it is issued and add the SCT to the certificate.

The idea is that ultimately clients won't accept a certificate from an SSL server unless a verifiable log entry is provided. Also Google expects organisations to act as auditors of the log and check the log is valid at all times. They also expect other organisations to monitor the log and to check multiple certificates have not been issued to a domain by different CAs etc.

The Spec

The RFC explains the protocol between the entity logging the certificate (CA or domain owner etc) and the log, it describes the protocol used to retrieve log entries as well as the log entry format and it describes the format of a SCT.

The log format uses a Merkle Hash Tree to make the log efficiently verifiable.

Roles

To try and untangle how this works I thought it would be useful to layout the roles:

• Relying Party - This is the SSL client accessing a server using the SSL protocol. As well as the server certificate they will verify the Signed Certificate Timestamp (SCT) they got either via some gossip protocol, from the server or from the certificate.
• Domain Owner - has a domain with an SSL enabled server and a key pair with a public key certified by a CA.
• CA - The CA issues the certificate and may or may not log the certificate with one or more public logs.
• Log - Receives certificates from either the Domain Owner or the CA and adds them to the log. The Log is responsible for publishing the certificates it receives but not for checking they have not been misissued.
• Auditor - An auditor periodically fetches log entries from a log and checks they are consistent (i.e no deletions and all additions since the last log it fetched are consistent).
• Monitor - An 'interested party' (according to the RFC) that follows the log and checks for misissue of certificates.

Issues

There are a bunch of things in this spec that I am not sure about. Mostly they are to do with the roles of the players and how they interact so I thought I'd sort my issues by role. Also, I think that while on the face of it the spec is intended to be simple, the interactions are not simple and if you merge the interactions of the entities introduced by the certificate transparency system with the existing relationships present in a PKI, the picture gets very complicated very fast.

Relying Party

The relying party gets an SCT (somehow) and then has to verify this. If the Relying Party doesn't verify the SCT then it could have been from a bogus log and there may be nobody checking for misissue. This feels like it is just shifting the problem as you have to somehow trust the log. To validate the log you could:

• Validate the Log server certificate using a trusted root in your trusted root store. The problem here is that a bad CA could issue a bad log certificate as well as a bad server certificate (i.e. the log server could be controlled by the MITM in the same way as the fake SSL server).
• You could maintain a list of trusted log server certificates. Then the problem is how to maintain this. Log servers are identified as 'good' or 'bad' based on reputation but there is no mechanism to publish the reputation of a log server. An RP can't measure the reputation for themselves as it would require a significant database of certificate to audit the log. If an auditor detected misbehavior of the log, how do they get this information out to RPs?
• You could use a consensus model so if you have at least some number of SCTs from different logs (and each has been signed by different CAs) then you accept it. This is better except you need to use the SCTs provided by either the CA (via OCSP), the server (via an SSL extension). You can't go to your favourite log and request a log entry for a certificate as there is no protocol defined for this (no way to search by certificate). Hence the bogus server could give you m SCTs signed by bogus log servers and your browser would have to accept it as m is a sufficient number. You could choose to only accept a consensus of logs that you trust but this leads me back to my previous point which is how do you manage your set of trusted log servers.

I get the feeling that the Relying Party is also expected to check (somehow) with other Relying-Parties to see if the certificate THEY got when they talked to the SSL server was the same. This idea was originally proposed by Moxie Marlinspike as certificate pinning. The spec doesn't propose a technique for doing this.

While not stated explicitly, the spec seems to imply that the presence of an SCT somehow provides some surety against misissuance. I can't see how this could be true as it depends on the certificate having been checked for misissue and not on the presence in a log. In section 7.1 of the RFC it says:

   Misissued certificates that have not been publicly logged, and thus
   do not have a valid SCT, will be rejected by TLS clients.

But what about misiussed certificate that HAVE been logged and not detected? Or even logged and detected but where the CA has not revoked the certificate? Once the system is up and running maybe this might be true but...

Certificate Authority

So the CA sends certificate it issues to one or more logs to allow independent entities to verify them. But why would the CA do this? You could argue because it makes the CA more trustworthy (DigiNotar seems to think it does as it is the first one to sign up to the program and start sending its certs to Google's log). The thing is that the CA is paid by the Domain Owner and *not* the Relying Party. 

The CA could implement its own log monitor and consult this log monitor as part of the certificate issuance process to guard against misissue. But then can't they do this now? Having public logs of SSL certificates does help picky relying parties of course as CAs generally wouldn't publish the certificates they issue to anyone other than the domain owner.

Now if the certification bodies that guard the trusted root store of browsers etc required all CAs to log all SSL certificates then that would motivate CAs to do this. How would that policy be written however? Especially how does this work if you are aiming for a soft, anybody-can-run-a-log-server consensus model based system with public, unrelated auditors/log owners? Or do you require them to write to specific well know logs which brings me back to having sets of trusted logs and my argument that this is just shifting the problem.

Also the mechanism for embedding an SCT in a certificate is problematic for most CAs. Most CAs have an RA infrastructure which is basically a big database of certificate requests plus some workflow for authorising those requests. When the request passes through this workflow it gets sent to some signer process to sign the certificate and that process usually runs on a more secure computer in different network segment.

Having to send the pre-certificate for signing, log the pre-certificate and then re-sign it would significantly complicate this workflow for most CA systems. In short the CA vendors will hate it and try not to implement this option. I could be wrong but that is my prediction.

Auditor

The role of the Auditor is pretty well defined - it periodically fetches log entries and ensures the latest log head is valid.

Again - the auditor does not check for misissue but only for bad log behaviour.

If the auditor does find a problem, what does it do? There is no reputation system for logs defined. Contacting the log operator will not help the relying party.

The spec says the Relying Party could be an auditor for the logs it uses but while you don't have to store all the log entries, fetching enough entries to ensure the log is valid sounds like a lot of data (and a lot of traffic for the log server if each Relying Party does this).

Log

How do we get a Log certificate? There are no CA policies for this are there?

It could be self-signed but this leads me back to the trust problem.

Using the domain SSL certificate seem problematic (risky).

Monitor

This is probably the most important entity but it is the least well defined. The problem is the criteria used are not defined and in fact it might be tricky to detect misissue (lets face it - CA's have trouble doing this too. If it was easy we wouldn't need this spec).

Then there is the problem of how to report the findings of the monitor back to the CA. Will the CA even respond?

The alternative to reporting bad certificate to the CA is to publish reputation scores for CAs but this requires another level of protocol. Also now we are checking the reputation of the CA using the monitor and the reputation of the log using the auditor but who checks the reputation of the monitor? On it goes...

Other Ideas

The domain certificate is really a binding between the domain name and the key. In other words the CA lets you be sure that if you can verify the communications with the key you must be talking to the right domain.

In actual fact it is usually a two step link in that the CA validates the identity of an organisation or individual and validates (via whois or whatever) that they own the domain.

The domain registrar must have already done this validation when issuing the domain. If the domain registrar issued a certificate to the domain owner, then the CA could just challenge the domain owner to sign something to check they own the domain and the validation problem becomes simpler. Also, if the CA publicly logged the information used to validate domain ownership it could be audited or independently validated as part of certificate issuance.

Conclusions

Right now there is no quality control for certificates issued by CAs so any initiative in this space is a good idea. CAs are paid by the Domain Owner not the Relying Party so some form of independent quality control seems warranted.

The certificate transparency model does have some merit as a means of quality checking CAs but I don't think having the Relying Party check SCTs makes any sense. I think it would make more sense to mandate CAs undergo quality control checks.

You could mandate CAs publish their SSL certs to a TTP log and have one or more independent monitors validate the logged certificates and then define mechanism for the CA to respond when a problem is encountered. This way the basic PKI mechanisms for the Relying Party stay the same.

Strengthening the validation of domain ownership or making the validation transparent seems like a better move than using heuristic techniques for identifying misissue.