let's encrypt made a huge improvement on the status quo, but now that 95% of the web depends on them, they're an obvious central point of vulnerability for censors and spy agencies
...you're not concerned about all of the other Trusted Root CAs that ship in OS/browser updates? Why would the NSA/GCHQ/etc need to compromise a high-profile target like LetsEncrypt when they could bribe any of the dozens of companies names listed in my own local certmgr.msc that I don't recognize at all[1].
1: I'm seeing names like "Actalis", "Baltimore CyberTrust", "Cetrum" - some of these sound more like pharmaceuticals than tech companies...
I'm more concerned about why I can't see a list of sites that CA has authenticated, or put my own restrictions on them.
Taking the first one: AC Camerfirma S. A.
I suspect I've never authenticated anything against that CA. I'd love to know what sites it has authenticated, and maybe I'd be happy with a lot of .es sites
Wouldn't surprise me if I rarely if ever encounter 80% of the CAs that I trust. Looking through I'd be happy if some of the signed .ae, or .cn, but not .de.
If I did visit an unusual CA, I'd like to make a judgement call on that access. Sure, the big ones (letsencrypt, globalsign, etc) woul dneed to just trust completely, but having a "you are visiting youremail.com, last time you visited this was signed by Globalsign with a certificate expiry of 5 months time, today it's signed by Odd Looking CA, continue?
Sure for 90% of users would click though, and it shouldn't be an option for 90% of users, but I'm not 90% of users.
Same with importing. If I make my own certificates for my own stuff, I want to import my CA and trust if for .mydevdomain.com, but not for mybank.com, because I don't trust my own security enough to have anyone, including me, have a skeleton key to my entire communication chain for key sites.
That's all available from Certificate Transparency. Chrome refuses certificates that haven't been submitted to CT.
AC Camerfirma seems to operate multiple CA certificates (e.g. some labeled by year). Here's a search that finds certificates issued by one of them: https://crt.sh/?Identity=%25&iCAID=51020
a compromised root ca allows an attacker who already has dns or ip control (via bgp, arp spoofing, a captive portal, etc.) to leverage it into a working mitm attack on a tls site, but it can't revoke certs it didn't sign, and the attack is over as soon as the attacker loses dns or ip control
by contrast, the ca you chose to sign your cert can revoke it, or refuse to renew it, taking your website permanently offline with zero effort on their part, unless you can find another ca to sign a new cert for you
but if you could, let's encrypt wouldn't have had to exist in the first place
the dozens of companies you mentioned make that less of a threat, not more of one, though they do of course increase of mitm attacks as i described in the first paragraph of this comment
> a compromised root ca allows an attacker who already has dns or ip control
DNS or host/IP control is not a requirement at all: a Trusted CA is already trusted to sign a certificate for any hostname (with exceptions): that's what Trust means, and it also means that we trust them not to issue certificates for domains/hostnames without doing at-least Domain Validation - and we have schemes like Certificate Transparency to help bolster that trust, but it still doesn't prevent an already-trusted CA from issuing its own certificate for, say, google.com or microsoft.com. This is why techniques like Certificate Pinning and co/counter-signing, and others exist - but they're only useful when the client isn't a human-operated web-browser ("smart clients", "IoT", etc). EV certificates were (amongst other things...) meant to help protect against small-time crooks but again, don't help when the CA itself is compromised.
if i type https://gmail.com/ into my browser, it usually doesn't matter if you have successfully gotten comodo or actalis to issue you a fake certificate for gmail.com, because my browser doesn't try to connect to your malicious server; it tries to connect to google's actual gmail server, and so you don't receive my packets, and your fake certificate does you no good
but, as i said, if you can feed me fake dns results so i connect to the wrong ip, or if you can arrange so that packets to gmail's legitimate ip go to your server instead (for example by having me connect to your wifi), then you can leverage the fake certificate into a successful mitm attack
but your explanation of the part of the basics of tls you understand, incomplete though it is, is irrelevant to the attack i was actually discussing, where someone doesn't like what you're saying (or the communication service you're providing) and gets your cert revoked to shut you up
If the browser enforced that the certificate had been issued in line with the domain's CAA record, such an attack might be less tractable without DNS control...
Let’s Encrypt, like other major CAs, participates in Certificate Transparency for this reason. “Central point of vulnerability” means very little without actual evidence of compromise, which CT would give us. And we haven’t seen any such evidence.
As far as I know. LE does not get access to the sites private key so they can not intercept traffic using their certificates. And if LE tried to replace certificates with fake ones, it would be spotted through certificate transparency like normal.
