Hacker News Reader

Comment by farhanhubble | Hacker News Reader

Why was anyone using certificates from a little known company with no cybersecurity muscle?

Web PKI doesn't work like you think it does. I can use eMudhra's private keys to forge a cert for your website. You don't have a choice in this.

What about CAA records? And of course, browsers handle this with the Certificate Transparency log and the OneCRL, made less painful by baking a short-lived proof that the cert is not revoked into the handshake. The problem is all the other parts of the ecosystem that basically ignore all this new complex security stuff and just check the cert against a static list of vendored roots.

For example, node, java, and python all have vendored roots and don't check any CRLs.

CAs check CAA records, clients don't.

Oh - I thought clients did. Was there some separate kind of cert pinning that clients checked that disappeared because nobody could get it right?

There's no reason clients couldn't, as far as I know (just like the various anti-spam measures where clients check for records that indicate what servers are allowed to send mail from a domain and consider it spam if those records don't match), but I also don't know of any clients that actually do. And a CAA record still doesn't actively prevent issuance of a certificate, which is really what would be needed.

There used to be a pinning scheme called HPKP, but the trouble with it is it's very easy to accidentally (or via malicious third-party action) end up in a situation where your web site becomes unreachable by people who've visited it previously because the key changed and the pin prevents their browser recognizing the new key as valid:

https://scotthelme.co.uk/im-giving-up-on-hpkp/

Clients cannot because the current CAA spec only requires that it be checked/valid at issuance time.

Thus, as a client, it is impossible to distinguish between:

1) A certificate that was issued in violation of a CAA record

2) A certificate that was issued correctly for a website that later changed their CAA record

There's also the basic problem that an attacker who can serve you a falsified A record for a domain can also serve you a falsified CAA record. This is why CAs are required to use "multiple perspectives" when validating domain ownership before issuing certs, whereas web clients generally don't have access to redundant infrastructure like that.

> What about CAA records?

Well, what about them? If you've got access to the private key, nothing is going to stop you from generating a cert violating CAA records - and it won't even be easy to detect! They are intended to protect against, say, someone hacking into your server, running ACME to get a cert, cleaning up their traces, and then intercepting your traffic for 90 days. CAA records assume the CA is trustworthy and following the rules.

Worse yet, why is that CA even part of the Root CAs shipped on all the modern devices?

My trust in those vetting the CAs is completely broken now.

It's not. The CA in question is an intermediate CA that somehow managed to convince a root to sign their public key.

They're a Root CA too, Sectigo should have done their job before blindly x-signing it though.

They were a root CA.

It might have been little-known in your corner of the world, but I understand it's definitely not little-known in India.

You might have heard of DigiCert or IdenTrust, but what, exactly, makes them trustworthy, and why eMudhra wouldn't be considered trustworthy (a week ago)?

You might have heard of this "sovereignty" movement: sovereign OS, sovereign cloud, sovereign AI?

One man's "little known company with no cybersecurity muscle" is another one's "sovereign certificate infrastructure."

It mostly does not matter. They don’t have your private key, and EVERY trusted CA can miss-issue in your name, regardless of who you pick.

That’s sort of the problem the CA forum (badly) addresses. The consumers of the CAs are not specifically exposed to failures of the CA they choose.

Reply on news.ycombinator.com