Very probably I'm missing something, and I love Let's Encrypt and the service that they provide, but... the point of Let's Encrypt is to bring SSL/TLS to more websites, right (and not necessarily to provide identity verification, since the automated renewal process doesn't really require any proof of identity for the entity requesting the certificate)? Why couldn't that have been accomplished using self-signed certificates, and having browser vendors remove their big scary warning pages for sites using self-signed certificates for SSL/TLS?
Do certificates from Let's Encrypt provide any security benefits over a self-signed certificate?
They verify domain ownership. If browsers accepted self-signed certificates, then as long as I could intercept your DNS requests (running a public Wi-Fi network next to a Starbucks, for example) then I could bring you to my malicious google.com without you knowing. That's no good.
The issue with browsers just allowing self-signed certs is that you cant verify their authenticity - ie were they correctly issued for the domain, or is it someone acting as the website using an invalidly issued cert. Having certs come from a recognized certificate authority helps with this because it provides a point for the certificate to be verified for authenticity
This makes me wonder about the feasibility of performing an attack by
* man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the domain validation challenge)
* requesting a new certificate for that domain
* spoofing the HTTP resource response (or DNS response, if applicable)
I suppose this is mitigated by the way Let's Encrypt validates the agent software's public key on first use though, at least for websites that are currently using Let's Encrypt.
While LE is indeed vulnerable to this kind of (difficult) attack, I wanted to make the point that LE still represents, for the most part, an improvement over the previous norms in the CA industry. ACME standardizes automated domain ownership validation to a relatively small number of options that have received relatively rigorous security review (leading to one being dropped due to security concerns, for example).
In contrast, incumbent low-budget CAs have often been a bit of a wild west of automated validation methods, often based on email, that can and do fall to much simpler attacks than a large-scale on-path attack. While CA/B, Mozilla, and others have worked to improve on that situation by requiring CAs to implement more restrictive policies on how domains can be validated, ACME still represents a much better validated, higher-quality validation process than that offered by a number of major CAs for DV certificates.
One approach to decentralized or at least compromised-CA-tolerant TLS is something called "perspectives" (also implemented as "convergence"). The basic concept is that it's a common attack for someone to intercept your traffic, but it's very difficult for someone to intercept many people's traffic on the internet. So, if the TLS certificate and key you receive from a website is the same as the one that many other people have received, it is most likely genuine. If it's different, that's an indicator of a potential on-path attack. This can be implemented by establishing trust between your computer and various "notaries" which basically just check the certificate from their perspective and confirm that it matches yours.
I bring this up, because if you squint just right you can view ACME as being a method of bolting the same concept onto the existing CA infrastructure: before you connect to a website, LetsEncrypt acts as a notary by connecting to the domain from multiple perspectives and ensuring that the same person evidently controls it from all of them. While not perfect, this is a strong indicator that the person requesting the cert is legitimate.
The on-path attack risk is almost, but not always, on a late stage of the network path to the user (e.g. their local network). The big weakness of the ACME approach is an interception of a late stage of the network path to the server. This tends to be much better secured, but hey, it's still something to worry about. There is obviously also a reliance on DNS, but I would say that DNS has basically always been the most critical single link in on-path attack protection.
> man-in-the-middling Let's Encrypt and a particular domain (or DNS, depending on the domain validation challenge)
Let's Encrypt issues multiple verification requests from multiple servers in different locations, both physically and in the network topology. If you can MITM that, you've pretty much taken over the domain and the ability to get a certificate isn't the worst of the operators problems.
> and the ability to get a certificate isn't the worst of the operators problems
That assumes a lot about the operators goals and values. It may very well be their worst problem. Eg. a journalist in a dictatorial area will very likely prefer not to have a cloud service than to upload his data into some compromised service.
It's just that, if it is their worst problem, TLS is patently insufficient, so they must think about it when setting the system up.
Yes, this could work, and has definitely been done, sometimes, against other public CAs. We found convincing evidence of this during work at one of my previous employers.
But what tempers my concern over that finding is that we found this by looking at cases where there's clearly a DNS takeover - and actually it was rare to do certificate issuance. In most cases it seems if you can MitM say, an Arab's country's army headquarters group mail servers, you can just offer no encryption or serve a self-signed certificate and the users will accept that. So while the Ten Blessed Methods are, as expected, not enough in the face of a resourceful adversary (in this case perhaps the Mossad, NSA or similar) they're also a padlock on a fence with a huge gaping hole in it anyway, our first attention should be on fixing the hole in the fence.
Usually lower energy to exploit the server running the ACME client or the infra around it than it is to subvert the Internet infra that surrounds the LE infra.
For instance, you can subvert the internet infra around some ccTLD if you're that country pretty easily but then who really owns the domain? Probably you, the country, since you can do anything with the DNS and then anything with the traffic.
Ah yes, that makes sense. Let's Encrypt requires proof of domain ownership, which at least ensures that the entity you're connecting to is the entity that owns the domain. Encryption without authentication wouldn't be very helpful, since a man-in-the-middle could just present their own self-signed certificate during the handshake...
You'd be protected from a passive attack and thus you could always (with enough effort) detect an attack. Someone who is snooping (e.g. fibre taps) is potentially undetectable (yes in theory there are quantum physics tricks you could do to detect this, but nobody much is really doing that) whereas an active attack is always potentially detectable.
So it's not nothing, but it isn't very much without the Certificate Authority role.
I'm somewhat familiar with certificate handling in general, I had just forgotten how Let's Encrypt performs domain validation; it's been a few years since I used it and it's worked so well that I haven't had to think about it since, which is probably a testament to its stability!
To be sure, PKI and certificates in particular have a lot of room for improvement in the UX department. Especially on Windows, where one frequently has to deal with not just .pem files but .cer, .pfx (with or without private keys), and more.
