Hacker News Reader

Comment by mjg59 | Hacker News Reader

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.

View on HN

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.

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.

Ok. That's an argument you can make. Now go back and make that in the first place rather than diverting everyone down an incredibly tedious demonstration of you making assertive statements that are just factually wrong. There's space to talk about what tradeoffs are reasonable here (eg, if this is something you're concerned about, you can pick a CA that's not in a hostile country, and you can enable certificate stapling at the cost of increased fragility and depending on some level of TOFU), but when you start the conversation by just being clearly wrong and then double down on that when multiple people suggest that you're wrong and point at resources indicating that you're wrong, you're not doing a great job of making that space available.

It's the argument I made at the top:

> The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer.

It's probably fair to say I've been a bit over assertive about CT, but it's all in the margin to me. No amount of technical complexity can turn community trust into direct trust. TLS is a community trust model and DNSSec is a direct trust model. The fact that CT is a pretty good community trust model and that browsers have (so far) done a pretty good job at keeping the CT community small is interesting, but it doesn't turn community trust into direct trust. So while I'd agree it's an incredibly tedious tangent, I'd say it's tedious moreso because the pro-CT folks are missing the forest for the trees than for any technical details about CT.

Edit: because community trust fundamentally relies on the notion of the community taking action against bad actors. Whether it's a CA or a CT log provider, and whether it's malicious action or a bug or just ceasing to do business, community trust has a time axis where membership in the community changes and notions of keeping devices up to date and political struggles ("too big to fail") and the like that simply aren't needed in direct trust.

CT trust does not in fact rely on "the community" at large taking action against bad actors. The history of CA surveillance will avail.

Of course it does. CT trust relies on root programs removing bad CAs and root programs and security researchers sharing information about bad CAs with root programs. The root programs, CA, and security researchers are colloquially "the CA community".

This kind of handwaving summary would be more credible if it hadn't been preceded by a long thread where it was made clear you didn't understand how CT functioned, at, like, a very basic level. You entered this conversation stridently equating CT monitoring with things like revocation checking.

I'm not looking for a debate; I'm just calling out things you say that are misleading and moving on. You're welcome to dispute my callouts! I'm satisfied that the thread establishes which arguments are credible and which aren't.

You are looking for a debate, I think. It's the whole thread. You're nerd sniping. It's classic.

You're not a fan of DNSSEC and prefer CT. When faced with examples where CT doesn't cut it, you refuse to discuss the big picture, pounce on incorrect details, and then resort to claiming your opponents are uninformed or arguing in bad faith.

The bottom line is my original big picture claim, the part that's on-topic for the article - that CT works for browsers on personal computers but not other classes of internet connected devices - it's true! And you know it! But you'd rather debate the details than inform readers about what they actually want to know (the big picture - i.e. that DNSSEC is useful).

I've observed your behavior before on hacker news, but experiencing it directly is eye opening.

It is difficult to make any sense out of your claim that internet connected devices can't benefit from CT. The initial claim you made was based on the unreliable connectivity and update channels of those devices, neither of which are especially implicated in enforcing CT --- your belief was that devices went and checked CT logs over the Internet on the fly to validate certificates, which, of course, no.

Ironically, this actually is a problem for DNSSEC validation! It's the literal reason why Chrome pulled its original DNSSEC/DANE implementation from the browser.

It's not a completely nonsensical concern - Chrome relies on a reliable connection to Google in order to get log list updates and do SCT auditing. If an attacker can block log list updates for long enough, CT enforcement is disabled entirely (i.e. certificates with no SCTs will be accepted), and if they can block SCT auditing for long enough, bogus SCTs will not be detected. This fail-open behavior was an intentional design choice so that CT would never break the Internet, as DNSSEC so often has. I think CT made very sensible tradeoffs here, but I understand matthew9219's complaints even if the details aren't entirely correct.

I'm hung up on the idea that challenges keeping a log list updated disqualify CT, thus motivating deployment of DNSSEC, a protocol so dependent on a clean connection to the Internet that its deployment in browsers on modern operating systems was derailed.

I acknowledge that embedded systems are a difficult place to do the policy-driven cryptographic security that we're talking about when we talk about the WebPKI and DANE. They're difficult for all sorts of reasons and they're difficult for all of software security, not just this. But they're pretty clearly also not a motivation for the deployment of DNSSEC; in fact, they're a sort of worst case for DNSSEC.

That's what this whole long subthread is about. It wasn't a strong argument. The thread has mostly been attempts to lay out why it isn't, without any interesting evidence for DNSSEC's suitability being presented.

Reply on news.ycombinator.com