| ▲ | farhanhubble 7 hours ago |
| Why was anyone using certificates from a little known company with no cybersecurity muscle? |
|
| ▲ | baobabKoodaa 6 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | aftbit 6 hours ago | parent [-] | | 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. | | |
| ▲ | crote 5 hours ago | parent | next [-] | | > 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. | |
| ▲ | kam 5 hours ago | parent | prev [-] | | CAs check CAA records, clients don't. | | |
| ▲ | aftbit 5 hours ago | parent [-] | | Oh - I thought clients did. Was there some separate kind of cert pinning that clients checked that disappeared because nobody could get it right? | | |
| ▲ | kensey 2 hours ago | parent [-] | | 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/ |
|
|
|
|
|
| ▲ | denysvitali 7 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | kijin 6 hours ago | parent [-] | | It's not. The CA in question is an intermediate CA that somehow managed to convince a root to sign their public key. | | |
|
|
| ▲ | Kwpolska 5 hours ago | parent | prev | next [-] |
| 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)? |
|
| ▲ | lokar 6 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | maratc 6 hours ago | parent | prev [-] |
| 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." |
