4 ms·

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 veri

by pfg 10y ago

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.

rkangel 10y ago
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.
- cm2187 10y ago
  Hence whoever maintains this list will be able to observe the traffic on a third party website.
  - rkangel 10y ago
    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.
  - pfg 10y ago
    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 http://www.certificate-transparency.org/how-ct-works
    - xnyhps 10y ago
      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.

by pfg 10y ago

rkangel 10y ago

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.

cm2187 10y ago
Hence whoever maintains this list will be able to observe the traffic on a third party website.
- rkangel 10y ago
  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.
- pfg 10y ago
  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 http://www.certificate-transparency.org/how-ct-works
  - xnyhps 10y ago
    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.