IIRC Let's Encrypt are more strict in their validation (HTTP, DNS and SNI) than the least onerous authorities before them. The difference is that they are automated and free, but I don't think that I can get any cert I couldn't get before (either for payment or free).
No you are not correct and I've been downloaded by people that don't know the history of DNS Certification Authority Authorization (CAA), which became required in 2017.
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.
This is really a drawback of the browser though, right?
Let's Encrypt is about making traffic https not giving you strong verification of the other party. It's right there in the name!
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)
> Unfortunately the "YOUR BANK LTD" certs have a major drawback: No obscure / arbitrary subdomains.
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.
Is your argument honestly that paying less than $10 is a sufficient deterrent for a serious attacker? To take advantage of a mis-issued certificate to begin with
requires more resources than that.
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.
The reality is that it isn't the $10 or the wildcard $120; it's the credit card that matters. When Let's Encrypt works in a scriptable context it means that something that used to be manual and a judgement call is now something that is routine.
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.
Forgive me for further splitting hairs, but you can buy SSL certificates without a credit card or proof of identity (Namecheap + Bitcoin since 2013 being one but not the only opportunity).
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.
I don't think this changed what you think it changed
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... ]
[ 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_
