But also, There is no choice now. Best we can do is encourage people to use web browsers that let people visit http sites, and afaik, that doesn't exist anymore.
Chesterton's Fence - why did everyone start encyrpting their websites?
His critiques of why LE is flawed security wise are spot on and I suspect something like SSH keys as he suggests would be pretty much as good.
But there's a reason we're encrypting everything, and the time when we started encrypting offers a clue as to why. Mass surveillance threat actors are not going to go to the trouble and visibility of MITMing every cert connection, but they will (and in the case of NSA did) happily go to the trouble of hoovering up network traffic en masse and watching how people surf. HTTPS provides some protection there because it at least hides the paths to the specific pages you are reading as you surf online, including things like search engine query terms.
The idea that $3.6m is a lot of money to encrypt a huge chunk of web traffic, or that Google is eagerly guarding the money it makes (?) off web certs, which must be a tiny fraction of its actual income, is a clue that this is maybe not a greedy conspiracy.
I think that if we didn't do TLS, every ISP would be injecting ads into websites these days. Making it difficult for middle-of-the-road interlopers is a good thing. ISPs don't want the customer service burden of proxy configurations and custom certs (god knows your IT department hates the support aspect of this tampering), so TLS keeps us free of excessive advertising. (Of course, they like do tampering with DNS which is why we have to do DNS-over-HTTPS. If you make it easy to tamper with your traffic, your ISP has a good business case to tamper with your traffic. Sad but true.)
I'm not as convinced as the author is that nation states can easily tamper with certificates these days. I am not sure how much CT checking we do before each page load, but either nation states are compelling the issue of certs that aren't in the CT database, or they are and you can just get a list of who the nation states are spying on. Seems like less of a problem than it was a decade ago.
The author seems to miss the one guarantee that certificates provide; "the same people that controlled this site on $ISSUANCE_DATE control the site right now". That can be a useful guarantee.
I also want to mention that several governments probably have large-scale tapping infrastructure to passively record Internet traffic. However, they like people not to pay attention to that or think about it (because, you know, we might try to protect ourselves or even try to get them to stop!). This is especially true when your communications cross national borders, as many governments have promoted a theory that normal privacy rules (that they might accept in other contacts) shouldn't apply at the border or outside of their territory.
HTTPS is a really important defense against this, but it's really hard to know when it worked or when it was relevant, because the wiretappers weren't announcing what they were doing and similarly don't usually announce when it's being thwarted.
There are lots of limitations there. For example, traffic analysis may sometimes allow identifying pairs of people who communicate with each other in low-latency ways like a real-time call, or possibly also those who communicate in a distinctive way in high-latency ways. It may also allow determining, for example, which Wikipedia page you looked at, because the pages are different sizes and contain different numbers of images, so the timing and volume of your browser communications could be distinctive depending on which page you browsed to. But, if you don't do the HTTPS part, then you're basically just saying "we're going to allow anyone who controls network infrastructure to permanently record 100% of all communications in an easily searchable way, if they so choose".
> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. In other words, Let's Encrypt certificates don't stop the one thing they're supposed to stop.
But the certificate is signed with the key of Let's Encrypt and your own, both of which the private key never leave the server.
> Not this time. The technical problems are easy to solve. For decades, users of SSH have had a system (save the certificate permanently the first time you connect, and warn if it ever changes) that is optimal in a sense: it works at least as well as any other solution. It's trivial to implement, is completely free, involves no third parties, and lasts forever. To the surprise of absolutely no one, web browsers don't support it.
This is completely backwards: TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank, and (2) shouldn't be exposed to any MITM risk because they forget to. The entire point of a public key infrastructure like the Web PKI is to ensure that technical and non-technical people alike get transport security.
(The author appears to unwittingly concede this point with the SSH comparison -- asking my grandparents to learn SSH's host pinning behavior to manage their bank accounts would be elder abuse. It works great for nerds, and terribly for everyone else.)
> The official way to renew Let's Encrypt certificates is automatically, with a tool called certbot. It downloads a bunch of untrusted data from the web, and then feeds that data into your web server, all as root.
Why would you run certbot as root? You don't do that with any other server.
His points aren't bad, but it seems like a great example of "perfect is the enemy of good." Let's Encrypt does an incredible amount of good by adding SSL to sites that wouldn't have had it otherwise.
- He sees it as a Trojan Horse, and fears for what will happen in the future
There are a few static sites I run where there is no exchange of information. I'm locked into ensuring certificates exist for these sites, even though there's nothing to protect (unless you count the ensuring the content is really from me as protecting something).
> You can make the warning go away by paying a third-party—who then pays Google—to sign your website's SSL certificate
This is just not true!!!! CAs don't pay google to be in their root store.
> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too
The reasoning goes that most MITM (potential) attacks are between you and your ISP. Let's encrypt can connect to the backbone basically directly, so most MITM attacks won't reach them. Also, starting on September 15, 2025 (Let's encrypt has been doing this for a while already though) all domain validation requests have to be made from multiple perspectives, making MITM attacks harder.
https does 2 things: encrypt the communication (self-signed certificates are good enough for this), and verify that the site you are connecting to is what it seem to be, because a certification authority trusted by your browser signed the certificate that that site presents, and it should had validated somehow that the site belongs to its rightful owner.
The second part is the important one in this context, because there are ways to trick your dns resolution or ip routing. The dns resolution part is mitigated with DoH (that it also uses https with certificate), but that doesn't covers everything.
It might not be so fundamental for some just browsing sites, but for the ones you send data (not just credit card info) you may run into some risks.
Self signed certificates really aren't good enough for encryption, unless you're doing TOFU before the MITM happens.
Otherwise the evil MITM can decrypt the traffic, modify/inspect it, and re-encrypt it with their own self-signed certificate, and you're none the wiser.
ACME renewal feels less like a time bomb than traditional renewal, even though it happens more often. Showing manually-renewed certs expiring as evidence for why ACME is a bad idea is literally completely backwards!
> My medical opinion: if it hurts, maybe you should stop doing it.
Funny enough, that's the exact opposite of the common wisdom for deployment:
> If it’s painful, do it often.
The idea is that if you were to wait months between deployments and do enormous deployments, there is a very good chance that you will have problems every time. First of all, if it's infrequent, you can tolerate things like downtime windows for deployment, which are unideal. Second of all, it batches tons of changes at once, which increases the chances you'll need to roll it all back. Thirdly, it makes it harder to even figure out what went wrong, since the problem-causing change could've gone in months ago.
By having ACME renewel happen very often, it should become apparent very quickly when they're not working, much closer to when you made the change that broke it. I believe this is an improvement full-stop. If you want it to work even better, add alerting when the certificate gets too old and monitoring/observability on the renewal processes. That gives you multiple layers of assurance that you probably wanted to have anyways.
Finally, it seems like the importance of encrypting all Internet traffic is just missing from the calculus presented here; that's just silly. I'm not going to go into it. It isn't imperative that literally every website is always encrypted all of the time, but for a multitude of reasons it is ideal if 99% of them are 99% of the time. Let's Encrypt might allow for a MitM if you can pass HTTP-01 or DNS-01 momentarily, but you know what's even easier? Just being literally anywhere in the path of someone's HTTP connection and being able to perform a MitM with having compromised nothing about the CA system or the website itself. Even if we allow for some sites to sit back on HTTP, it matters that 99% of the Internet is on HTTPS because it makes MitM attacks like this highly unattractive. This is good when you're on untrusted or potentially adversarial networks... Which is increasingly many of them.
The other thing missing here is just how clever the CA system has gotten. Mozilla and Google have together made this system work surprisingly well despite its flaws. The CT system makes issuing bad certificates very unattractive, as Google and Mozilla can fiercely enforce the rules, and CT makes it nearly impossible to hide when you go against them. With CT, CAA records, and other tools available, you can at least know with damn near certainty if someone did exploit the CA system or your infrastructure and pull certificates for your properties. With these improvements, relying on the CA system doesn't feel nearly as ugly.
And also, you don't necessarily need to use LE. I think LE is the most competent of the ACME providers, but many paid services provide ACME support, and ZeroSSL provides another free ACME service.
Shorter lived certificates also have other benefits that are not mentioned. For example, if certificates can last 5 entire years, a revoked certificate also has to be able to last that long. This makes CRLs pretty much untenable, and forces something like OCSP, which is bad for privacy. Shorter certificate lifespans were a big part of how Firefox was able to leave OCSP behind in favor of a more advanced version of the CRL scheme, a solid win for both privacy and TLS latency.
All in all, the juice is clearly worth the squeeze.
57 comments
[ 3.9 ms ] story [ 64.4 ms ] threadBut also, There is no choice now. Best we can do is encourage people to use web browsers that let people visit http sites, and afaik, that doesn't exist anymore.
(Hugs)
His critiques of why LE is flawed security wise are spot on and I suspect something like SSH keys as he suggests would be pretty much as good.
But there's a reason we're encrypting everything, and the time when we started encrypting offers a clue as to why. Mass surveillance threat actors are not going to go to the trouble and visibility of MITMing every cert connection, but they will (and in the case of NSA did) happily go to the trouble of hoovering up network traffic en masse and watching how people surf. HTTPS provides some protection there because it at least hides the paths to the specific pages you are reading as you surf online, including things like search engine query terms.
The idea that $3.6m is a lot of money to encrypt a huge chunk of web traffic, or that Google is eagerly guarding the money it makes (?) off web certs, which must be a tiny fraction of its actual income, is a clue that this is maybe not a greedy conspiracy.
Please do tell. I'm curious what forced him to join The Borg.
I'm not as convinced as the author is that nation states can easily tamper with certificates these days. I am not sure how much CT checking we do before each page load, but either nation states are compelling the issue of certs that aren't in the CT database, or they are and you can just get a list of who the nation states are spying on. Seems like less of a problem than it was a decade ago.
The author seems to miss the one guarantee that certificates provide; "the same people that controlled this site on $ISSUANCE_DATE control the site right now". That can be a useful guarantee.
HTTPS is a really important defense against this, but it's really hard to know when it worked or when it was relevant, because the wiretappers weren't announcing what they were doing and similarly don't usually announce when it's being thwarted.
There are lots of limitations there. For example, traffic analysis may sometimes allow identifying pairs of people who communicate with each other in low-latency ways like a real-time call, or possibly also those who communicate in a distinctive way in high-latency ways. It may also allow determining, for example, which Wikipedia page you looked at, because the pages are different sizes and contain different numbers of images, so the timing and volume of your browser communications could be distinctive depending on which page you browsed to. But, if you don't do the HTTPS part, then you're basically just saying "we're going to allow anyone who controls network infrastructure to permanently record 100% of all communications in an easily searchable way, if they so choose".
But the certificate is signed with the key of Let's Encrypt and your own, both of which the private key never leave the server.
This is completely backwards: TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank, and (2) shouldn't be exposed to any MITM risk because they forget to. The entire point of a public key infrastructure like the Web PKI is to ensure that technical and non-technical people alike get transport security.
(The author appears to unwittingly concede this point with the SSH comparison -- asking my grandparents to learn SSH's host pinning behavior to manage their bank accounts would be elder abuse. It works great for nerds, and terribly for everyone else.)
But it's really not, as countless comments here in this thread have correctly pointed out.
Why would you run certbot as root? You don't do that with any other server.
- It introduces an exploitable attack vector
- He sees it as a Trojan Horse, and fears for what will happen in the future
There are a few static sites I run where there is no exchange of information. I'm locked into ensuring certificates exist for these sites, even though there's nothing to protect (unless you count the ensuring the content is really from me as protecting something).
Also by the author: https://michael.orlitzky.com/articles/in_defense_of_self-sig...
This is just not true!!!! CAs don't pay google to be in their root store.
> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too
The reasoning goes that most MITM (potential) attacks are between you and your ISP. Let's encrypt can connect to the backbone basically directly, so most MITM attacks won't reach them. Also, starting on September 15, 2025 (Let's encrypt has been doing this for a while already though) all domain validation requests have to be made from multiple perspectives, making MITM attacks harder.
The second part is the important one in this context, because there are ways to trick your dns resolution or ip routing. The dns resolution part is mitigated with DoH (that it also uses https with certificate), but that doesn't covers everything.
It might not be so fundamental for some just browsing sites, but for the ones you send data (not just credit card info) you may run into some risks.
Otherwise the evil MITM can decrypt the traffic, modify/inspect it, and re-encrypt it with their own self-signed certificate, and you're none the wiser.
> My medical opinion: if it hurts, maybe you should stop doing it.
Funny enough, that's the exact opposite of the common wisdom for deployment:
> If it’s painful, do it often.
The idea is that if you were to wait months between deployments and do enormous deployments, there is a very good chance that you will have problems every time. First of all, if it's infrequent, you can tolerate things like downtime windows for deployment, which are unideal. Second of all, it batches tons of changes at once, which increases the chances you'll need to roll it all back. Thirdly, it makes it harder to even figure out what went wrong, since the problem-causing change could've gone in months ago.
By having ACME renewel happen very often, it should become apparent very quickly when they're not working, much closer to when you made the change that broke it. I believe this is an improvement full-stop. If you want it to work even better, add alerting when the certificate gets too old and monitoring/observability on the renewal processes. That gives you multiple layers of assurance that you probably wanted to have anyways.
Finally, it seems like the importance of encrypting all Internet traffic is just missing from the calculus presented here; that's just silly. I'm not going to go into it. It isn't imperative that literally every website is always encrypted all of the time, but for a multitude of reasons it is ideal if 99% of them are 99% of the time. Let's Encrypt might allow for a MitM if you can pass HTTP-01 or DNS-01 momentarily, but you know what's even easier? Just being literally anywhere in the path of someone's HTTP connection and being able to perform a MitM with having compromised nothing about the CA system or the website itself. Even if we allow for some sites to sit back on HTTP, it matters that 99% of the Internet is on HTTPS because it makes MitM attacks like this highly unattractive. This is good when you're on untrusted or potentially adversarial networks... Which is increasingly many of them.
The other thing missing here is just how clever the CA system has gotten. Mozilla and Google have together made this system work surprisingly well despite its flaws. The CT system makes issuing bad certificates very unattractive, as Google and Mozilla can fiercely enforce the rules, and CT makes it nearly impossible to hide when you go against them. With CT, CAA records, and other tools available, you can at least know with damn near certainty if someone did exploit the CA system or your infrastructure and pull certificates for your properties. With these improvements, relying on the CA system doesn't feel nearly as ugly.
And also, you don't necessarily need to use LE. I think LE is the most competent of the ACME providers, but many paid services provide ACME support, and ZeroSSL provides another free ACME service.
Shorter lived certificates also have other benefits that are not mentioned. For example, if certificates can last 5 entire years, a revoked certificate also has to be able to last that long. This makes CRLs pretty much untenable, and forces something like OCSP, which is bad for privacy. Shorter certificate lifespans were a big part of how Firefox was able to leave OCSP behind in favor of a more advanced version of the CRL scheme, a solid win for both privacy and TLS latency.
All in all, the juice is clearly worth the squeeze.
A MITM attack against your renewal does not expose your private key. I don’t think that causes the harm the article suggests.