How does Certificate Transparance detect fake or forked logs?

Question

I am trying to understand Certificate Transparency.

Let's say I want to snoop on somebody's email. So I go hack or bribe a CA, have them issue a certificate for google.com, and then I present it when I MitM the users connection to Gmail. This is the situation that CT is trying to detect, and allow Google find out about the false certificate.

With Certificate Transparency, the users browser will require that I attach a signed certificate timestamp (SCT) proving the the certificate has been added to a log.

• First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?
• Can the browser tell if a log is legitimate?
• Does the browser or its Auditor component send the SCT to Monitors?

Alternatively I could hack/bribe a log operator to issue an SCT with the tree hashes of it together will all the previous certificates. Then when Google and others query the log for its certificate chain it could pretend that the bad SCT never existed. This would be a fork in the log. Again Google would only find out if the browser (Auditor) sends the SCT to Google or other Monitors.

The CT website mentions that "auditors and monitors exchange information about logs through a gossip protocol", but never goes into any details about how or when.

• Specifically, how does the browser (Auditor) know which Monitors to talk to?

Answer 1

First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?

Nothing.

Can the browser tell if a log is legitimate?

It's left unspecified in the RFC:

TLS clients [...] should validate the SCT by [...] using the corresponding log's public key. Note that this document does not describe how clients obtain the logs' public keys.

(Note: This sentence was removed from section 5.3 the new RFC that's currently in development. I don't know if they replaced it with anything more specific)

But Chrome for example will by default only trust a handful of hard-coded logs:

By default, Chrome will check SCTs coming from a list of predefined CT logs recognized by Chrome.

.

Does the browser or its Auditor component send the SCT to Monitors?
[...] Specifically, how does the browser (Auditor) know which Monitors to talk to?

It depends. As per the Gossip RFC draft this would be the Trusted Auditor Relationship type of gossiping. (Which is 1 of 3 types of gossiping proposed. And all of these mechanisms may be used in parallel.)

And the RFC draft goes on to say that:

The Trusted Auditor Relationship is expected to be the rarest gossip mechanism, as an HTTPS Client is providing an unadulterated report of its browsing history to a third party. While there are valid and common reasons for doing so, there is no appropriate way to enter into this relationship without retrieving informed consent from the user.

So I guess it's gonna be either manually configured or configured to come from some trusted party (browser manufacturer I guess).

###Update 2018-01-26Fri.: @__agwa-Blog. There's a recent blog post on this topic:

• Andrew Ayer, 2018-01-10, How will Certificate Transparency Logs be Audited in Practice? (Archived here.)

It's an in depth technical read. The TLDR is this last paragraph here:

All of this is a ways off. CTv2 is still not standardized. Chrome still doesn't do any SCT auditing, and consequentially its CT policy requires at least one SCT to be from a Google-operated log, since Google obviously trusts its own logs not to break its promises. Fortunately, even without widespread log auditing, Certificate Transparency has been a huge success, cleaning up the certificate authority ecosystem and making everyone more secure. Nevertheless, I think it would be a shame if Certificate Transparency's auditability were never fully realized, and I hope we'll be able to find a way to make it work.

Answer 2

• First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?

Looking at the documentation it appears that this is a requirement for solving that:

From the page you reference: "Every certificate log must publicly advertise its URL and its public key (among other things). Anyone can interact with a log via HTTPS GET and POST messages."

The monitors are capturing the state of these logs and making sure they are consistent with their history. Presumably, if the auditor is not aware of the log, it would immediately relate that back to the browser [More below].

• Can the browser tell if a log is legitimate?
• Does the browser or its Auditor component send the SCT to Monitors?

Again, from the page you reference: "Most auditors will likely be built into browsers. In this configuration, a browser periodically sends a batch of SCTs to its integrated auditing component and asks whether the SCTs (and corresponding certificates) have been legitimately added to a log. The auditor can then asynchronously contact the logs and perform the verification."

It you try to create your own log or corrupt it, the monitors would be able to detect that. I'm a little uncertain about the term "periodically" above. I'm not sure I understand the batching or SCTs. Would that mean that browsers would assume the SCTs were good until they were informed otherwise? It seems like a hole to me. I would think you would want to immediately verify any new certificate when it was presented.