[DethNinja]

Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that.

Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions.

Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the moment.

Certificate system is actually rather insecure, and although solutions are possible to develop, nobody has taken time to do it.

[nmjohn]

> Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that.

Yes they do. Only firefox doesn't.

[siebenmann]

Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.

[jsmith45]

The SCT is a promise of the log to include the certificate (or pre-certificate, which is used for embedded SCTs) within a time window. The only way a cert could have a valid embedded SCT is to have actually sent the pre-certificate to the log in question.

The SCT contains a signature over some log related information (which is also included in the SCT itself) and everything in the pre-certificate except the signature and poison (which means everything in the real cert, except the SCTs and signature). This means the browser can reconstruct the signed data and verify the signature.

Thus the only way to have a valid SCT and not have at least the pre-certificate show up in the log (after the merge delay) is if the log operator/software messed up. For transparency purposes, a pre-certificate is basically as good as a full certificate, although if I recall correctly the CAs are also supposed to submit the full certificates too.