The security industry has no shortage of hard problems to solve, but the one that’s getting the most attention right now is finding a way to improve, or ideally, replace, the CA infrastructure. The latest in what has become a series of recent proposals to help shore up the certificate authority system comes from a pair of Google security researchers who have laid out a plan for providing auditable public logs of certificates as well as proofs for each certificate that’s issued.

The system proposed by Google’s Adam Langley and Ben Laurie comprises three separate ideas, but relies on the creation of a publicly viewable log of every public certificate that’s issued by a CA. There could be any number of public logs of these certificates, but the logs will be structured so that they are append-only. The entries in the logs will be the end certificates in the issuance chain. In addition to the logs, the proposal includes the use of proofs that are sent with each certificate to the user’s browser. Laurie and Langley haven’t defined exactly what the proof would look like, but suggest that it could be an extra certificate or a TLS extension.

“As the log grows, new entries will be periodically signed using a signed Merkle Tree. The log will be publicly available for download (probably in chunks corresponding to the Merkle signatures). Thus, domain owners can monitor the logs for certificate issuance for their domain. If a certificate is issued that should not have been, then the domain owner will have proof of that fact (the mere existence of the certificate is sufficient). And since browsers will check the Merkle proofs (see below), it will not be possible to issue a certificate that does not appear in the audit log,” the researchers wrote in their paper, “Certificate Authority Transparency and Auditability”.

One of the main problems that the proposal is meant to address is that of attackers being able to compromise CAs in one way or another and issue their own certificates for domains they don’t own. This has happened a couple of times in the last year, with the attack on Comodo and the compromise of DigiNotar later in the year. The attacker, who appears to have been the same in both cases, was able to issue valid certificates for a large number of domains, including Google, Skype, Yahoo, CIA and others.

Laurie and Langley’s proposal contemplates three different scenarios that could occur if a CA issues a certificate that it should not have, either by mistake or through a compromise. If the bad certificate doesn’t appear in a public log and none of the logs colludes with the CA, then the client will reject the certificate. If the certificate is in a public log, then the browser will acept it, but the legitimate owner of the domain will be able to see it and have it revoked. In the third scenario, if the certificate isn’t in the public log and a log provides the CA with a fraudulent proof for it, then the browser would accept the certificate, as well. But that proof eventually would be seen to not correspond with the public logs and would also serve as proof that the log that colluded with the CA had acted badly.

The researchers say that their proposal should be highly backward compatible with existing browsers and servers. It would mainly require just a configuration change on the server side, and if an older browser wasn’t able to read the public certificate logs, it would just ignore the extra code.

The proposal from the Google researchers is the latest in a line of ideas meant to address the inherent weaknesses of the CA system. Researcher Moxie Marlinspike has rolled out an entirely new system called Convergence that relies on notaries rather than the existing CA infrastructure. And the EFF has proposed another scheme called Sovereign Keys that is designed to associate specific keys with specific domains.

Categories: Critical Infrastructure

Comments (3)

  1. Soroush Dalili (

    Unfortunately it cannot solve the most important problem as well. They are just moving the attack point to another server! It is similar to DNS but for certificates. It can even be more vulnerable and slow down the process.

    Those attacker/hackers who can replace the server certificates, simply can redirect a valid Certificate Checker/Resolver server to their infected server with fake inputs. It is even easier than the previous process.


  2. Anonymous Coward

    Hm, public logs of chains, Merkle trees and proofs, sounds very much like the Google engineers were inspired by a similar combination of technologies called Bitcoin.

    One particular adaptation of this is Namecoin, a distributed DNS alternative based on cryptographic proof of work instead of trust in centralized authorities and security by obscurity. Basically there are no systems to hack, you can’t fake entries unless you have (significantly) more computing power than half of the participants in the entire network, which quickly rules out even the most potent supercomputing clusters. If this was adopted on a large scale you would basically need a botnet of hundreds of millions of hosts to overwhelm it, at which point you would have a much larger and immediately obvious problem anyway.

    Something similar could be done for CAs as well. The most important advantage of this (open source) technology is that it’s not controlled by any one commercial or governmental entity. It is decentralized, so it’s very hard to subvert or bring down as long as there is basic connectivity in the network.

  3. Rune K. Svendsen

    In my opinion, Namecoin (or some variant of it) is the solution to this problem. When someone registers a domain using Namecoin, she can simply include a public key in the registration. Now we just connect to this particular domain and all data we send will be encrypted with this public key, and the data that is sent back is encrypted with the client’s public key that she sends to the server in the initial handshake. No need for certificates as long as the server can keep its private key private (which isn’t too much to as I think).

Comments are closed.