[matthew9219]

The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates.

Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.

[tptacek]

That's not how any of this works. Clients don't download the CT logs.

[matthew9219]

Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding.

The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.

[mjg59]

No, because the presented certificate won't have any SCT entries (which are embedded in the certificate), and you can't fake the SCT entries without having access to the CT private keys.

[matthew9219]

> you can't fake the SCT entries without having access to the CT private keys.

So... Governments like the US and China can fake the entries by using their police forces to seize the private keys?

SCT has the same set of problems as TLS - any log will do, not just logs from countries you trust.

[mjg59]

This is why multiple SCT entries are required. Could you subvert all of this with enough effort? Yes, and the same is true of dnssec. Any form of cryptographic validation is only as secure as the control of its private keys, but modern TLS is designed to require you to compromise at least 3 independent parties in the TLS ecosystem to provide a plausible fake. And at that point why not just get the browser vendor to push a fake update to the user that disables TLS validation entirely? You're either doing all validation yourself, or you're trusting someone. Modern TLS avoids you needing to place trust in any one organisation from the TLS perspective, which makes attacks on other infrastructure components much more appealing.

[agwa]

This is not an accurate description of how CT provides security.

To begin with, CAs are allowed to operate logs themselves, so the minimum number of independent parties is 2, not 3.

Second, CT log private keys are not particularly well-protected. They are not stored in HSMs. One log's private key has been presumed compromised since 2020 because the server running the log was pwned via a vulnerability in the Salt configuration management system. SCTs from this log are still accepted by Apple (and by Chrome, until earlier this year) for satisfying the minimum SCT requirement.

Rather, CT provides security by using a Merkle Tree so that SCTs can be audited. In theory, clients can demand proof that an SCT is really included in a log, and gossip tree heads with monitors to ensure that monitors have the same view of the log as them. If an SCT fails auditing, or a log is found to have presented inconsistent views of its Merkle Tree, this can be detected and the log can be distrusted. In practice, this is quite challenging. Apple currently doesn't audit SCTs at all; Chrome probabilistically audits a subset of SCTs.

[matthew9219]

The crucial difference is who decides which cryptographic entities to trust. With TLS and CT, the browser defines the list of entities and if 3 or more of those entities live in a hostile country, you can be compromised. With DNSSec and CAA, the site operator gets to define the list of entities.

[agwa]

You are almost correct. The claims are called SCTs (precertificates are something else). The SCT is a promise by the log that they have (or will soon) publish the certificate. The promise could be lie. To detect that, the client is supposed to audit the SCT. If the audit fails, the client reports it so the log can be distrusted.

So yes, it's true that if an adversary can permanently silo off a client, it can prevent log misbehavior from being detected, either by blocking the reporting of audit failures, or by presenting a completely different view of the log to to the client. However, in many cases it would be impractical for an adversary to keep up such an attack forever, so CT still has value and I'm a huge fan of it. But it's true it can't stop literally all attacks.

Source: I run the CT monitor which has detected misbehavior in multiple CT logs.

[tptacek]

I don't think you're providing clarity at all, because that attack doesn't work.

[matthew9219]

If you wanted to use your words to explain why you think that, that might be more constructive. I could well respond "yes, it does work" but that wouldn't be useful. I know you're an expert in the space and might appreciate learning from you, but this is not that.

[tptacek]

I'm sorry, but I'm declining to do that, because I recognize the message board conversational pattern where all the information you have about the subject is coming from comments rebutting you (this is apparent from things you've said already that fundamentally misapprehend how CT works), and, rather than acknowledging any of that information, you just use it as vocabulary for new misapprehensions.

[nickf]

Clients do not get pre-certs. Those are generated by the CA, and submitted to the log in return for an SCT. Forging a ‘fake CT log’ isn’t possible, either. Nor do clients talk to CT logs, at all.

[matthew9219]

> Forging a ‘fake CT log’ isn’t possible, either

Why do you think this isn't possible?

[nickf]

Aside from what mjg59 said, it's clear you don't quite understand how CT works. Logs are stood up and then go through a fairly rigorous acceptance process by Google (and Apple) before finally being used. 'Used' in that a CA can then submit pre-certs to it and include the resulting SCTs in signed certificates, making them functional on Chrome/Apple platforms. Even the CA using the log generally takes some communication with the log operator to ensure the right set of roots are trusted for submitted pre-certs.

CT logs are used by CAs, not clients. A 'fake' log isn't a thing.

[michaelt]

If you are able to compromise a CA and generate a bogus certificate, why couldn't you also compromise a certificate transparency log provider and generate a bogus signed merkle hash?

(Not that I'm a DNSSEC user myself, my feet aren't bulletproof)

[mjg59]

Because they don't have access to the private key material owned by the CT logs that the browsers trust when validating SCT data in the certificate.