Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.
Now they can just use Let's Encrypt.
Google deemed the failure rate of ~2% too high but I hold out hope that banks and other high value targets will use DANE in tandem with the traditional HTTPs CAs and use something like HSTS except instead of requiring HTTPS for a particular domain, will require DANE. Maybe something like viewing your account will accpet a CA signed cert, but an actual money transfer goes through a subdomain that required DANE.
[0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
But DANE enforced by clients would also be quite valuable for preventing problems due to CA misissuance, or for the problem recently highlighted by security researchers that someone might deliberately allow a domain to expire while still possessing long-lived certificates for names under that domain.
Let's Encrypt launched 2016, which meant that unless you were doing HPKP with long pin times and had traffic that already had hit your endpoint, if someone was on your gear (but lacked your private key) they could impersonate you for free and with no messing around with stolen credit cards to CAs.
To verify for Let's Encrypt—contrary to what you recall—all you are required to prove is that you can set a specific value at a path for the domain you are responsible for.
DNS verification is an option; but few use it.
Let's Encrypt has meaningfully reduced the barrier for certificate forgery. Every startup should set CAA headers now, but few do. It's still good that Let's Encrypt exist but it has its drawbacks.
The browsers do show some things for better verified certificates e.g. "YOUR BANK LTD." on a banks cert, "Secure" on hacker news/My page secured with let's encrypt.
So controlling traffic on the domain is really sufficient for the promise that LE is trying to make to you which is "When I accessed this domain, the entity that owns this key controlled the traffic. I don't really know anything about the entity."
If you think that presents a vulnerability then it's because you're equating https with entity verification (and I don't blame you because the browsers have trained us to do this)
And I agree with your conclusion HTTPS is better than HTTP, but it doesn't mean we're talking with whom we think.
Why is that a drawback from a user POV? I wish sites would try hard to keep there stuff in one part of the DNS name-tree if only to make uMatrix easier to use. I'm glad of anything that encourages them to do so.
It's disingenuous to call this certificate forgery. If your gear is owned or somebody is in a position to perform active MITM on you, then WebPKI doesn't give a damn about your situation to begin with. It's not part of the security model they're concerned with. DV does exactly what it says on the label, and Let's Encrypt did nothing to change that.
I know this seems like splitting hairs, but it's actually mattered to some of my clients. Try to reverse the chessboard. This is exactly how things slip in and this is really being used in the wild.
I think this $ thing is an arbitrary line in the sand based on an imperfect picture of how things used to be, and how things used to be did not protect domain owners. Getting certificates mis-issued used to be waaaay easier than it is now (even without demonstrable control of the domain/website). There were a tonne of insecure methods provided for in the BRs and there was no visibility into it until CT came along.
Historically a Certificate Authority did whatever it pleased to validate control over the name. It is _definitely_ true that an adversary who "was on your gear" could get a certificate.
Once the CA/B Forum comes into existence (which is when those green bar "EV" certificates appear) there are rules for how to do this validation, but, crucially, those rules have a clause which says "Any other method". Yup, CAs were still free to do whatever they wanted.
By 2010 or so they could get a "free trial" certificate, which would be annoying for a real site owner but crooks don't care about that, the "free trial" period is long enough to get the job done, and if the site's actual owners get billed for exceeding their "free trial" well boo hoo.
In 2016 the CA/B voted on new rules for validation which got rid of "Any other method" but although the vote passed, it was tied up in lawyer hell because it turns out commercial CAs owned patents on lots of crappy methods.
In summer 2017 Mozilla got tired of the foot-dragging caused by lawyers and simply changed _their_ trust rules, which in effect unilaterally changes the rules for a public CA since "Our certificates don't work in Firefox" might as well say "We don't want to be in business any more, bye".
These new rules are the Ten Blessed Methods (but now only eight or nine are in use) but crucially Let's Encrypt, unlike a lot of commercial CAs, had been compliant from its creation, indeed its staff helped write them.
Your rosy view is totally wrong, here are two REAL examples of things actual publicly trusted CAs were doing prior to the Ten Blessed Methods which weren't even _prohibited_ even though they're worthless:
1. Send an email to administrator@example.com with a link in it. If the link is resolved, this validates that the legitimate owner of example.com wanted a certificate issued for any name under example.com
What if an "anti-virus" gateway dereferences the link to check if it's a viral payload before trying to even deliver the email?
"Hi, An Actual Criminal wants a certificate issued for login.yourbank.example. As the Administrator please click this link to authorise this certificate."
[ AV software dereferences link. Cert issued to An Actual Criminal. The system works... ]
"I'm sorry, administrator@yourbank.example doesn't exist"
[ Oh right, nobody at yourbank.example actually even saw the verification message. Well I'm sure it's fine ]
2. Tell the applicant to specify a URL where they can see a special one-time code, once the applicant confirms that's done check the one-time code is seen at that URL
What if the attacker suggests a URL that is just the one-time code, URL escaped, and the result is a 404 error reciting the code because that's just how your server's 404 errors work?
Nobody would accept a 404 error as proof? Right? Wrong. Well, OK, but once they fixed that it's fine, right? Wrong, lots of commercial HTTP servers don't send 404, they send a redirect and paste your message into the redirect, thus passing the test.
Let's Encrypt's design actually does a pretty good job here, if you feel this isn't enough then the reality is that before the Ten Blessed Methods many other trusted CAs were _worse_
The value of a CA is that it's a trusted 3rd party that holds a private key used to sign public keys (certificates). Never a CA should get hold of your private keys.
I'm not sure if you're referring to CAs' ability to issue fake certificates, or if you're suggesting that the certificate issuer can directly MITM connections.
CAs' ability to issue fake certificates is a very serious concern which has led to the Certificate Transparency system where all issued certificates must be publicly disclosed (in a system outside of the issuer's control) in order to be publicly trusted. A site doesn't have to use a certificate from a particular CA in order to be vulnerable to misissuance by that CA, as in the Iranian Comodo and DigiNotar attacks, where Gmail was briefly vulnerable to MITM attacked involving misissued certificates from these CAs even though it didn't normally use certificates from either of them at all.
CAs don't have the ability to use their signing keys directly to MITM connections involving certificates that they issued, because the signing key isn't used for any cryptographic purpose other than validating that the certificate (which refers to the site's public key) was validly issued.
Totally agree with your point about trust being a very hard problem to solve, that's why CAs first came in to place, and now we have CT (which is not widely adopted yet). It is a problem that has no clear and definite solution yet.
Edit: Also, CT is no magical solution. It's just another "node" in the graph of trust we're establishing. As many other things have in the past, the CT system itself could also fail.
[0]: http://www.certificate-transparency.org/certificate-transpar... , Certificate Inclusion Check
[1]: https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...
But this thread is operating under the thought experiment that the NSA already owns LetsEncrypt. And in reality-- at least according to the Snowden leaks-- NSA currently has classical MiTM capabilities. (Can't remember which program it was that was using some node between the user and the desired server to send back a forged response that would almost always beat the server to the punch.)
So in this thought experiment there are only two pieces of Triforce and NSA has them both.
These were called QUANTUM (with various sub-projects related to specific applications of that capability).
Also there _is_ a third piece of the triforce; certificate transparency logs; and those would be very difficult to compromise without the certificate transparency monitors noticing.
And if they were able to turn off certificate transparency logs or targeted users only without it (or a hacked browser or whatever) to keep site owners from knowing about invalid certs being given.
Also, why would they do this? It's smarter to compromise the existing CAs.
1) the honeypot uses your private keys to MITM connections
Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key.
2) the honeypot issues fake certs
Let's Encrypt submits a log of every cert issued, see https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.
If somebody has seen a proof that is contradicted by the published log state this means the Logs involved are corrupt. If an otherwise authentic cert is shown without proofs or those proofs are bogus the cert may have been unlogged for nefarious reasons, it shouldn't be accepted and needs reporting
Chrome has the start of this, it checks for the proofs. Firefox is getting roughly the same feature "soon". But the finished system with all bells and whistles is probably a year or five away.
Good news is that even unfinished CT has been very effective.