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.

(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.

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.)

Why would you run certbot as root? You don't do that with any other server.

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.

> 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.

  Issued to: michael.orlitzky.com
  Issued by:
  - Common Name (CN) E7
  - Organisation (O) Let's Encrypt

HTTPS does three interrelated things:

Encryption - the data cannot be read by an intermediary, which protects your readers' privacy. You don't want people to know what pages you read on BigBank.com or EmbarassingFetish.com.

Tamper Proofing - the data cannot be changed by an intermediary, which protects your readers' (and your server) from someone messing with the data, say substituting one bank account number for another when setting up a payment, etc.

Site Authentication - ensures that the browser is connected to the server it says it is, which also prevents proxying. Without this an intermediary can impersonate any site.

Before the big push for encrypting everything it was not uncommon to hear of ISPs inspecting all traffic to sell to advertisers, or even injecting ads directly into pages. HTTPS makes this much more difficult.

* Encryption is the first thing HTTPS does and the one I'd argue that actually matters the most. It prevents your ISP or other middle parties from snooping or modifying what packets end up being shown to the end user. This is something that fundamentally doesn't require a CA to work. A self signed certificate is just as secure as one issued by a certificate authority on the matter of encryption; you just run an openssl command and you have a certificate, no CA needed (although a CA could still be useful for ie. Trusting updated certificates in the same chain, there's little reason to demand this to be done through a third party from a security perspective.)

* The second one is identification. Basically, the certificate is meant to give the idea that the site you're visiting is trusted and verified to belong to somebody. This is what CAs provided... except in practice, CA identification guarantees basically doesn't exist anymore. Finding the entity a certificate is issued to is hard to do in modern browsers, ever since a security researcher proved that it's relatively trivial to do a name collision attack, so browser developers (aka Chrome and Mozilla) hide it behind click through windows and don't show them anymore by default. Since browsers mandate HTTPS for as many APIs as they can get away with, everyone including garden variety scammers just gets an HTTPS certificate, which utterly defeats the entire purpose. CAs are essentially sitting in the middle and unless a third party suddenly demands you get an OV/EV certificate, the argument to not just use the CA that gives literally anyone who asks a certificate after the barest minimum effort to prove they own a domain is pretty questionable. Your bank might use an OV/EV certificate, but your average person seeing the bank website will not visually see any difference between that and a scam site. Both got perfectly legitimate certificates; one just got them from LetsEncrypt instead, where they had to give no details on the certificate. Only nerds look at the difference when visiting sites, and more people than nerds use banks.

Since identification is utterly dead, the entire CA structure feels like it gives little security to a modern browser as opposed to just going with a TOFU scheme like we do for SSH. Functionally, a CA ran by a sysadmin has the exact same guarantee as a CA ran by LetsEncrypt on the open internet for encryption purposes, except LE gets to be in browser and OS root programs. They might as well have the same security standards once you bring in CAA records.

Final note: there's something backwards about how a plain HTTP connection just gets a small label in the browser to complain about it, while a HTTPS certificate that's a single minute out of date will lead to giant full screen red pages that you have to click through. For consistency, the HTTP page should be getting the same scare pages from an encryption perspective, but they don't.

I agree with much of this article. IMHO certificates signed by a certificate certbot are only marginally more secure than a self signed certificate. Basically you can prove your domain is yours with a certificate ... by proving your domain is yours to let's encrypt via a DNS check. That sounds a bit recursive. At this point there is not a lot being checked or verified by signing authorities.

IMHO the current focus on shortening certificate validity periods just highlights how inadequate certificates are and helps exactly noone stay safe. This is 100% certified a website. With a domain. Owned by somebody random on the internet. That's all that the certificate guarantees.

Any scammer learned years ago how to get certificates for their scam domains. Short of blocking those domains faster than they pop up (good luck), there's no way to derive any more meaning from those certificates than "this is a website".

It would help for there to be more authorities. And also to have longer expiry periods. I don't need this busywork in my life whether it's worrying about automating, monitoring, etc. or just about paying off some gate keeper for some meaningless check + bureaucracy. Longer expiry enables more strict/expensive checks to happen and browsers should be checking specific certificates against blacklists. Rotating certificates frequently makes both those things less practical and devalues the whole notion of a certificate. Any scammer will just use the same services to get the same kind of certificates.

Also, the reason we can't rely on the DNS yet, is that there is still a lot of legacy software relying on non secure ways to talk to the DNS. And that being a bit of infrastructure that predates the whole notion of having certificates also means that the biggest risk is a lot of legacy insecure DNS infrastructure that is easy to spoof and can't be trusted. Anyone see a problem with that and how certificates are issued? Otherwise, we could just stick our public keys in there and self sign our own certificates. But secure DNS is a prerequisite.

* domain has DNSSEC * domain has CAA records only allowing DNS challenge and disallowing insecure HTTP challenge

but if we rely on DNSSEC we can just use DANE/TLSA and don't need the mess of CA/PKI

So I’ve always been fond of it and never really thought twice of it. While it’s rare for companies to support a shared resource together, this was a situation where it made sense.

But this is a good reminder to be wary of even the most benevolent looking tools and processes.

Gimme self-signed certificates please. With the ability to verify that the certificate was signed by whoever controls the domain I'm accessing. Abolish all certificate authorities. That's all I ask.

For one thing the verification doesn't just make a single http request, it makes several from many different nodes. There is a risk that your hosting provider MitMs the verification, but you need some level of trust in your hosting provider anyway, and in some cases that is actually a feature, as it allows your hosting provider to manage the certificates for you.

And that is one way that traditional CAs verified domain ownership for DV certs.

Is it perfect? Absolutely not. Is it better than nothing? Absolutely.

I do wish that DANE, or something similar had caught on.

Also, if you trust Let's Encrypt to be your CA it seems very strange to consider certificates provided by them as "untrusted". Also, certbot, or many of the other options don't necessarily need to be run as root. And many webservers support getting acme certs themselves. Also, there is nothing stopping you from verifying the certs are valid before using them.

Also, with a short expiration time, automation is basically required, which means that you set up the automation, and some monitoring that the renewal happens correctly, and then just let it go. And your renewal process is continually tested. With manual renewal, you have to remember to renew it, and remember how to renew it, a long time after the last time you did it. It is much more likely that you forget.

I somewhat agree with the precept, it's not great that the web is controlled by Google, beyond just tls certs. Something that changed since this was written is precisely that you have alternatives like zerossl.

Saying that letsencrypt doesn't bring any security is plain wrong though. The OWASP top ten doesn't list certificate theft or chain of trust mitm attack, but does have a category for cryptographic failures. My hotel has full control of the wifi, but it hardly has an opportunity to mitm my chain of trust. Same goes for ISP. When you have a cert corresponding to your dns record, it at least shows that you have some control over the infra that is behind that record.