Certificate Transparency

Question

From what I read here, if the intermediate CA has been compromised, a fake cert can be issued and the privacy of the end-users could be compromised as well. In order to remediate this situation, someone have to report this and have this cert be revoked by the CA that issue the intermediate cert.

At the end of the article, it suggested CT (Certificate Transparency). I understand that CT's "auditor" will constantly query the "monitor" and "log server" to check for the validity of the cert. On the other hand, "monitor" will query the log server as well. However, one thing I'm not clear is that, how's CT going to help us if no one reported that the cert or CA has been compromised?

Also if it depends on others to verify the CA and cert can we think CT as a type of P2P CRL/OCSP?

Answer 1

Since I can't comment, apparently, I want to clarify a couple of points.

• CT does not require all browsers to use it: there is a herd immunity conferred even if only one browser does it. And, BTW, Chrome's next release includes CT support.

• Webservers do not have to change to support CT - CAs can include the SCTs in issued certificates. Some CAs already do this, and others are working on it.

• CT does not introduce a new trusted entity - CT logs prove their own correct operation, and any deviation leaves signed evidence of their wrongdoing.

• The goal of CT is to enable interested parties (domain owners, researchers, etc) to have full visibility of the public PKI so that misissue of certificates is easy to promptly spot. DigiNotar, for example, would have been discovered in hours instead of months had CT been deployed.

Answer 2

Certificate Transparency is a heuristic defence mechanism which does not detect misissued certificates; instead, it strives to allow faster detection of misissued certificates.

The core idea is that of Glasnost. It so happens that most successful attacks rely on an asymmetry of information. Suppose that I want to impersonate Google's server. Through deception, bribery, incompetence and/or luck, I obtain a fake certificate with "www.google.com" written in it. I will then use it for a fake server which responds only to my target victims (say, all the employee in a company where I have some sysadmin capabilities). My interest, as an attacker, is that nobody on the outside notices the existence of that fake certificate, in particular Google themselves. If the people at Google become aware of this certificate that bears their name, but is not one of theirs, then they will promptly talk to the issuing CA, and ask for immediate revocation. Harsh words can be expected.

Certificate Transparency is a public log of certificates. This is a system by which a SSL/TLS client (a Web browser) may be configured to accept a certificate only if it comes with a verifiable proof (the "Signed Certificate Timestamp") that the certificate has been added to a log where it will be visible to everybody, in particular the purported certificate owner (Google, in my example above). This does not guarantee detection; in fact, the certificate is technically completely valid. What CT guarantees is that whatever certificate any client sees is in plain view and thus, supposedly, will soon be detected if it is fraudulent.

(One may note that CT logs include timestamps which are signed by... a trusted entity ? As usual, no trust is ever created, just moved around.)

---

The weak part of CT is that it works only if everybody participates. CT offers actual security improvements only as long as the SSL/TLS clients (i.e. Web browsers) duly reject server certificates which do not come with the SCT. This works only if all of the following hold true:

• All CA participate, so that it can be expected that every "normal" certificate is in a CT log at some point.
• All Web browsers support CT and reject certificates which are not in the log.
• All Web servers support CT and send the Signed Certificate Timestamp objects to browsers using the specified SSL/TLS extensions.

I estimate chances of this system to actually complete its bootstrap phase to less than 10%.

Answer 3

PKI has two elements: the technical protcols and the procedures we build around them.

In the technical realm, things are pretty clear: you got mechanism that allows you to decide what to trust, when under what condition and how to communicate (most) changes in that trust system (CRL, OCSP, etc.).

These technical elements do not, however, cover the procedures: how to we know that such and such root can be trusted ? As a user, usually because you trust (implicitly) the company that builds and maintains your root CA list (Microsoft, Mozilla, Google, Apple, etc). As an actor, because you review the way these roots have been validated or validate them yourself (for instance, if you're using private roots, it's important to conduct a proper investigation on how they are managed).

So, how does one know that an (intermediate or root) CA has been compromised ? It can be because you spot some improper use of that CA (for instance finding a leaf certificate that is signed by a certificate that doesn't have the right to sign keys) but it most likely is always because of some procedural element: someone did an audit and noticed an inappropriate usage of said certificate.

In the specific case you linked, the issue was really of that nature: the ANSSI did something that it really wasn't supposed to do (issue a certificate in name of one entity to another unrelated entity) and that is why its certificate was revoked by Google and Mozilla.

This highlight the problem with the whole public PKI system: there are too many actors that must follow too many rules that are not trivial to understand and even less easy to follow. And it takes only one of the actors to fail for the security of the whole system to crumble: the whole thing is incredibly brittle.