Hacker News Reader

Hacker News

Comment by hbcdbff | Hacker News Reader

Parent Full thread

hbcdbff

CT is great for browsers. Largely irrelevant for anything being fetched outside of a browser.

View on HN

That’s why I’m talking about it purely in the context of incident response/forensics.

You claimed CT would “definitive”ly prove whether it has or has not been exploited, which is false.

The lack of CT entries only proves that (most likely) browsers were not MITM’d.

I'm not following. Browser or no browser, every cert eMudhra issues has to generate an SCT.

SCT enforcement falls to the client though, yeah? What's stopping someone from signing a rogue cert silently which is accepted by CT-lenient clients?

Right, but you don't have to wait for some hapless random browser to check; you can write your own monitor, and people do that.

I hold eMudhra's private key. I generate a cert signed by their intermediate on my box. eMudhra didn't issue the cert, so it is not sent to any CT logs, and I have no SCT to put in the cert.

Am I missing what you mean by monitor?

I think I might just be talking past you. If your point is "anyone with these broken eMudhra keys can attack users without caring about CT", that's totally true --- it's just that browser/no-browser doesn't factor into it. I'm really only on this subthread because of the notion that CT enforcement requires browsers.

Right, I think I'm with you that browser/no browser shouldn't be a factor. I think I'd like to hear from Rust and Go webpki people on whether we could help the ecosystem enforce CT.

My point is more that as a user of a high-level library like reqwest, I'd like to talk safer defaults when root CAs are in use

Right, OK, I was misunderstanding the point you were making. Thanks!

Sure, but a client that doesn't do CT wouldn't care if they don't include a SCT promise. [ed.: this said "break the SCT promise", that doesn't quite make sense] Which you'd only notice if you see the certificate somewhere else afterwards…

It's all rather hypothetical and unlikely, but you could certainly try attacking something like downloads.openwrt.org¹ like that — especially if you can tell apart the TLS client in opkg from a normal browser.

(¹ luckily, OpenWRT and most other package repos don't actually rely on HTTPS for package integrity and authenticity. And OpenWRT would be the most susceptible due to the "exotic" TLS client stack, if any.)

No, it doesn't. A certificate may or may not include CT info, or include fake CT info. Most TLS clients accept certificates without checking for CT.

I’m surprised to see this username above this comment.

No, the cert can be issued with no (or invalid/junk) SCT and will work fine with clients who don’t check SCT, which is most non-browser interaction.

To spell it out a bit further, an attack strictly in a non-browser context that is reasonably well targeted will most likely go undetected since what the attacker is up against is the chance of inadvertently running into a paranoid user who goes out of his way to perform verification.

Every cert an attacker issues with eMudhra's private key has to appear in the CT logs if they want it to validate in a modern browser.

But if you only want to MITM the connection used by 'pip' to install python wheels - that doesn't check for CT records at all.

Seems like we need to upgrade all software to start using CT records then?

We would still know if certs were issued, though, which is the thing we want to check

How would you know it? If the CA was compromised, why would the attacker publish the fake certificates in CT?

Basically no one outside the major browsers verifies CT logs, so you can still attack a lot of people even without publishing.

The baddies also take a look at the CT logs and look for fresh wordpress instances that haven't yet been configured and will helpfully configure them for you within a few minutes.

No we wouldn’t.

We wouldn’t.

CAs publish to CT logs. If an attacker has the private key, nothing stops them from signing certs without the involvement of the CA or CT logs.

Nothing stops them from doing so, but major browsers and possibly other programs won't trust such certificates. https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...

Yes but a lot of non-browser software doesn't check CT logs, so if an attacker were to target such software they could use an unlogged cert and no one would notice.

This is why there are OS trust stores. Electron - if you use the system CA [0] and cURL[1] apps use it, which are you talking about?

[0]: https://github.com/electron/electron/issues/45674

[1]: https://curl.se/docs/sslcerts.html

The CT log is a property of the individual leaf certificate not a property of the issuing chain. You could have the same CA in the trust store issue an unlogged certificate and non browsers would trust it.

A CT log isn't super relevant (it's not the CRL, it's just a log), but it's maintained/delivered by the CA not the leaf. Never the leaf.

If you mean CRL/Revocation list, everything but the root [you can't revoke a root] is maintained by the tier above. Leaf -> intermediate (these), [Intermediate -> Intermediate*], Intermediate -> Root.

Not sure why you're mentioning transparency logs, they have nothing to do with this (nor help).

Because the thread: "a lot of non-browser software doesn't check CT logs", you replied saying it's a reason to use the OS trust store, not sure how that fixes things? Maybe it would relieve them of the responsibility of pushing out a distrust update?

That's not what woodruff is talking about (I hope). The CT logs allow us to (later) find who/why it happened. CT Logs in no way help you stop something. (Depends a bit on how software reacts to apparently invalid issuance - but since these have the real keys the issuance will look normal).

Revocation lists allow you to stop/block bad issues. Both are maintained/decided (you could post to another service) by the issuer, not the leaf. CRL records would stop this (but some software has decided that's too slow). In general software uses the OS trust-store first (fragmented on Linux). Firefox and Java have their own independent paths. Chrome ignores CRLs

CT logs only tell you something happened if the certificate was registered in the log. But if you are attacking software that doesn't check if the cert was registered, then you don't need to register the cert, and there won't be anything in the log.

My point is you can forge a cert, without putting it in the log, and a lot of software will still be vulnerable to it.

Curl does not check that certificates have a valid SCT attached. Thus it will accept a certificate that isn't in the CT logs. That's mostly independent of the OS trust stores.

CT is enforced in Android 17 by default.

Reply on news.ycombinator.com