"Let's Encrypt is a golden example of how creating inalienable good is possible with the right approach and the right values. And while I'm excited about the work Let's Encrypt has done, I am eager to see their work continue to keep up with the growing Web; to sustain encryption for everybody at Internet scale. To do so is going to take more than me—it's going to take a community of people committed to this work. I am confident Let's Encrypt is a project that deserves all of our support, in ways both large and small." https://letsencrypt.org/2025/03/18/community-of-funders/
Ten Years of Let's Encrypt: Announcing support from Jeff Atwood

As we touched on in our first blog post highlighting ten years of Let’s Encrypt: Just as remarkable to us as the technical innovations behind proliferating TLS at scale is, so too is the sustained generosity we have benefited from throughout our first decade. With that sense of gratitude top of mind, we are proud to announce a contribution of $1,000,000 from Jeff Atwood. Jeff has been a longtime supporter of our work, beginning many years ago with Discourse providing our community forum pro bono; something Discourse still provides to this day.

@codinghorror

i don't agree that let's encrypt is good, at least not the way google and the eff promote it and treat https as a requirement as if they were the platform vendor of the web. the great thing about the web is that there is no platform vendor.

they premise their pitch on the idea that https is always good, but for sites that predate the broad adoption of https, it's not only unlikely someone is around to adapt the site, but it might be such a big job that it's impossible.

@davew @codinghorror Let’s encrypt is a bandaid on the broken system that is HTTPS, TLS, X.509 and CAs.

@ahltorp
to be fair, of that enumarated list, it is only the "trust random CA by default" idea that is completely broken.

If you run your own private CA and remove all other CAs from your browser list, it is very good idea and works great to only trust your approved sites!

What is broken is idea that just because someone paid some amount of money (or if they can prove temporary control of the domain in case of LE) that it somehow means the whole world should trust them!
@davew @codinghorror

@mnalis @davew @codinghorror I get what you mean, and I agree that the CA part is the most broken, but the SSL/TLS idea of making security “transparent” is also broken.

For better-than-nothing-security it works, but any real security needs to be bound to the application layer. The whole practice of TLS offloading is a symptom of that brokenness.

@ahltorp
Could you elaborate on that why you think it is less secure?

I find "transparent" (i.e. implicit) TLS (e.g. HTTPS == HTTP over TLS on TCP/443) to be MORE secure than L7 app-layer security (e.g. SMTP STARTTLS over TCP/25), because it avoids MitM attacks that skip encryption phase.

Of course, you could forbid communication if STARTTLS was skipped for example, but then it behaves like implicit TLS with extra unhelpful step. I.e. it's useless security wise.

@davew @codinghorror

@mnalis @davew The application layer has no idea if the communication is encrypted, and even if it does, it has no idea who it is talking to. There can be any number of MitM, and there often is.

STARTTLS only delays authentication/encryption, it doesn’t automatically bind it to the application layer.

But I guess TLS is so ingrained now that proper application layer encryption is almost unknown.

@ahltorp @[email protected]

i'm far from an expert on the technology of HTTPS, but I do know this -- you have no choice but to trust Google, who makes the dominant web browser. They get all your keystrokes and text in the clear. Any encryption system requires that but only a fool would put a surveillance capital company in that role. what are the chances they abuse the privilege? your mileage may vary, but it's not a good design for that reason alone.

@davew HTTPS is much more than web browsers, though. A lot, probably most, of the API traffic in the world uses HTTP.

But you are correct, Google is a very bad company to give access to your sensitive clear text. Their incentives are clearly not aligned with the users.

@ahltorp
AFAIK, all TLS MitM that exist are either due to users trusting random CAs (e.g. your typical corporate firewall "protection"), or due to users allowing nonencypted connections to exist (e.g. sslstrip).

TLS allows for both sides to be authenticated (although in most cases it is only server that is authenticated), and it allows passing encryption info to the app (see e.g. https://httpd.apache.org/docs/current/mod/mod_ssl.html for details)

As for APIs, they use same broken CA trust model as browsers...
@davew

mod_ssl - Apache HTTP Server Version 2.4