Hacker News Reader

Comment by cm2187 | Hacker News Reader

Does anyone knows how it's going to work in practice? I presume google would act as a monitor. Does that mean that chrome will download an exhaustive list of all valid certificates regularly? Or does that mean that chrome will verify the validity of a certificate with google's monitor regularly? On every request? Will google log what IP requested validation for what domain? Then isn't that a massive privacy issue? Or will monitors only be used as a ad hoc control tool, when google wants occasionally to check that a certificate is legitimate?

View on HN

For Chrome, the policy is that you need to deliver SCTs from a certain number of trusted Google- and non-Google log servers. These can be cryptographically verified to have been included in those logs. There's no real privacy issue because this does not involve any real-time queries from the client to those log servers; rather, the SCTs are either embedded in the certificate or delivered via OCSP or a TLS extension.

Chrome itself does not act as a monitor, that is left to domain owners. CT guarantees detectability, but only if someone's looking.

CT also has a gossip protocol that should help detect misbehaving log servers; I'm not too familiar with that protocol and whether Chrome has implemented any of it. That's an area where I guess there might be some privacy concerns to think about.

Realistically, Google will run a monitor. But the important thing to realise is that the monitoring process is completely different from the validation process.

The fundamental idea is to make all certificate creation public, by putting it in a publicly auditable list. THis allows anyone to check that someone else hasn't given out a certificate for their domain, or for a large chunk of the internet etc.

In order to make that work, you have to make all certificates that aren't in that list unusable, and you do that by having the browser check that the certificate it is checking is in the list.

Hence whoever maintains this list will be able to observe the traffic on a third party website.

That is an interesting point.

I suppose a client could act more like a monitor and download chunks of the log at a time, thereby hiding which site in the chunk they were interested in. That wouldn't be hugely efficient though.

No, that's not a valid conclusion. Browsers do not query log servers in real-time whenever they see a new certificate. Rather, servers send SCTs which are "a promise to add the certificate to the log within some time period"[1]. Comparatively speaking, think of this more like OCSP stapling as opposed to real-time OCSP queries.

Auditors and CT gossiping are responsible for ensuring that the log servers are not misbehaving.

[1]: http://www.certificate-transparency.org/how-ct-works

Correct. What might be interesting to add to this: you can't query Certificate Transparency servers by certificate. You can query them by index or by using an SCT hash, but if you want a definitive answer to "when was this certificate first logged?" you'll need to process the log completely. CT is not designed for live-checking of certificates, only for monitoring by domain owners.

A number of SCTs (basically statements signed by qualifying logs that they saw that certificate at time X) must be delivered to the client during the handshake. Those can be embedded in the certs (by using pre-certificates), included in the TLS message directly or as part of a stapled OCSP response.

Reply on news.ycombinator.com