Let's Encrypt did more for privacy than any other organization. Before Let's Encrypt, we'd usually deploy TLS certificates, but as somewhat of an afterthought, and leaving HTTP accessible. They were a pain to (very manually) rotate once a year, too.
It's hard to overstate just how much LE changed things. They made TLS the default, so much that you didn't have to keep unencrypted HTTP around any more. Kudos.
I think it was Snowden who made TLS the default. Let's Encrypt did great work, but basically having the NSA's spying made common knowledge (including revealing some things that were worse than we expected, like stealing the traffic between Google's data centers) created a consensus that unencrypted HTTP had to go, despite the objections of people like Roy Fielding.
"Let's Encrypt did more for privacy than any other organization."
LE allowed more sites to get certificates. This has obvious benefits for e-commerce, for example
But so-called "tech" companies, e.g., "Big Tech", have, since before and after LE was started, continued to perform the largest mass scale intentional erosion of privacy in human history
The exfiltrated data is encrypted in transit using TLS. This may prevent ISPs or other passive network observers from competing with the so-called "tech" companies in the data collection, surveillance and ad services business
Arguably the use of TLS certificates increases privacy from ISPs or other passive network observers, but it does not increase privacy from so-called "tech" companies, who are perhaps the greatest threat to privacy that computer users face. Their "business model" depends on violating privacy norms
And, in fact, commercial CA certificates as pre-installed in browsers and required on the www ("WebPKI") effectively obstructs computer users from monitoring their own egress traffic in real-time. Hence corporations and other computer users must work around "WebPKI" to perform "TLS inspection"
Yeah, I remember when HTTPS was a novelty, used mainly by e-commerce websites like PayPal. The sites that actually had secrets in their traffic that could be worth protecting, and were willing to pay tens of thousands to buy certificates and then pay the compute tax on the traffic encryption.
To play the devils advocate: TLS on websites where you are not logged in is the greatest security hogwash of all times.
For example the cookies of the NYT:
- Store and/or access information on a device 178 vendors
- Use limited data to select advertising 111 vendors
- Create profiles for personalised advertising 135 vendors
- Use profiles to select personalised advertising
- Understand audiences through statistics or combinations
of data from different sources 92 vendors
There is no way to escape any of this unless you spend several hours per week to click through these dialogs and to adjust adblockers.
And even if you block all cookies, ever-cookies and fingerprinting, then there are still cloudflare, amazon, gcp and azure who know your cross-site visits.
The NSA is no longer listening because there is TLS everywhere? Sure, and the earth is flat.
TLS is not just for encryption, but also for integrity. The content you are seeing is exactly as intended by the owner of the domain or webservice (for whatever that is worth). No easy way to mitm or inject content on the way.
"There is no way to escape any of this unless you spend several hours per week to click through these dialogs and to adjust adblockers."
I read NYT with no cookies, no Javascript and no images. Only the Host, User Agent (googlebot) and Connection headers are sent. TLS forward proxy sends requests over internet, not browser. No SNI. No meaningful "fingerprint" for advertising
This only requires accessing a single IP address used by NYT. No "vendors"
TLS is monitored on the network I own. By me
I inspect all TLS traffic. Otherwise connection fails
> The NSA is no longer listening because there is TLS everywhere? Sure, and the earth is flat.
I’d be very surprised if they haven’t had several of the root trust entities compromised from day one. I wouldn’t rely on TLS with any of the typical widely-deployed trust chains for any secrecy at all if your opponent is US intelligence.
TLS is cool for stopping your ISP from MiTMing your traffic (usually to insert shitty banner ads or something).
Otherwise I find it a scourge, particularly when I want to run https over a private network, but browsers have a shitfit because I didn't publicly announce my internal hosts.
There's plenty of traffic that has no need to be encrypted, and where not much privacy is added since the DNS queries are already leaked (as well as what the site operator and their many "partners" can gather).
I'm glad you can get free certs from Let's Encrypt, but I hate that https has become mandatory.
I remember deploying SSL on NetWare in the late 1990s and being given ... something that the US allowed to be exported as a munition!
I don't recall the exact details but it was basically buggered - short key length. Long enough to challenge a 80386 Beowulf cluster but no match for whatever was humming away in a very well funded machine room.
You could still play with all the other exciting dials and knobs, SANs and so on but in the end it was pretty worthless.
A few years ago a client of mine gave me a big-ish APC UPS. I recently got new batteries for it after the outage here in Portugal, and to turn on SSH I had to agree that I was not a terrorist organisation's nor in a country where encryption can not be exported to.
Has anyone considered the possibility that a CA such as Let's Encrypt could be compromised or even run entirely by intelligence operatives? Of course, there are many other CAs that could be compromised and making money off of customers on top of that. But who knows... What could defend against this possibility? Multiple signatures on a certificate?
Even funnier, if one SIGINT team built a centralized "encryption everywhere" effort (before sites get encryption elsewhere), but that asset had to be need-to-know secret, so another SIGINT team of the same org, not knowing the org already owned "encryption everywhere", responded to the challenge by building a "DoS defense" service that bypasses the encryption, and started DoS driving every site of interest to that service.
(Seriously: I strongly suspect that Let's Encrypt's ISRG are the good guys. But a security mindset should make you question everything, and recognize when you're taking something on faith, or taking a risk, so that it's a conscious decision, and you can re-evaluate it when priorities change.)
A signature on a certificate doesn't allow CA to snoop. They need access to the private key for that, which ACME (and other certificate signing protocols in general) doesn't share with the CA.
IF you accept CA certificate X as trusted, then you are assuming anything signed by X is who it says it is. HTTPS server certificates are signed by CAs.
The actual communication is secured by a public/private keypair which is separate from the CA certificate.
Browsers have a set of certificates "pre-accepted", these are the default root certificates. There have been issues with some of them over time (e.g. DigiNotar) and they hav changed over time. If you hear of someone speaking about the "CA cartel" this is what they mean.
So a compromised CA can make you think you are talking to someone, like your bank, when you are not. But it doesn't enable snooping on traffic on the wire.
A CA can protect from this compromise by keeping the root private key entirely offline and signing a couple intermediate CA certificates. Then, if one of those intermediate CAs gets compromised, it can be revoked and a new intermediate CA created. You as a user of the CA can't do much though-either you choose to trust it (or delegate that trust) or don't.
You can create your own self-signed root CA certificates and client/server certificates signed by that CA fairly easily. But you then have to add the root CA as a trusted certificate into every device you want to use it, including those of your friends, employees, etc. This isn't quite as bad as it sounds, the last time I checked even phones would install a new root CA certificate if you opened a .crt file, and deploying CA certificates via Microsoft Group Policy is a thing.
I mean, it doesn't help that the browser duopoly is making it harder and harder to use self-signed certificates these days. Why, if I were more paranoid, I might come to a similar conclusion.
So, the crucial thing ACME has that the other protocols do not is a hole (and some example ways to fill that hole for your purpose, though others are documented in newer RFCs) for the Proof of Control.
See, SCEP assumes that Bob trusts Alice to make certificates. Alice uses the SCEP server provided by Bob, but she can make any certificate that Bob allows. If she wants to make a certificate claiming she's the US Department of Education, or Hacker News, or Tesco supermarkets, she can do that. For your private Intranet that's probably fine, Alice is head of Cyber Security, she issues certificate according to local rules, OK.
But for the public web we have rules about who we should issue certificates to, and these ultimately boil down to we want to issue certificates only to the people who actually control the name they're getting a certificate for. Historically this had once been extremely hard core (in the mid-1990s when SSL was new) but a race to the bottom ensued and it had become basically "Do you have working email for that domain?" and sometimes not even that.
So in parallel with Let's Encrypt, work happened to drag all the trusted certificate issuers to new rules called the "Ten Blessed Methods" which listed (initially ten) ways you could be sure that this subscriber is allowed a certificate for news.ycombinator.com and so if you want to do so you're allowed to issue that certificate.
Several ACME kinds of Proof of Control are actually directly reflected in the Ten Blessed Methods, and gradually the manual options have been deprecated and more stuff moves to ACME.
e.g. "3.2.2.4.19 Agreed‑Upon Change to Website ‑ ACME" is a specific method which is how your cheesiest "Let's Encrypt in a box" type software tends to work, where we prove we control www.some.example by literally just changing a page on www.some.example in a specific way when requested and that's part of the ACME specification so it can be done automatically without a human in the loop.
This protocol definitely made securing the web easier. Thanks to it, I don't need to renew certificates manually (it's now done automatically), which can be tedious...
Can someone explain why letsencrypt certificates have to be 90 days expiry? I know there is automation available, but what is the rationale for 90 days?
Because companies can't be trusted to set up proper renewal procedures.
If a cert has to be renewed once every 3 years, plenty of companies will build an extremely complicated bureaucratic dance around the process.
In the past this has resulted in CAs saying "something went wrong, and we should revoke, but Bank X is in a Holiday Freeze and won't be able to rotate any time in the next two months, and they are Critical Infrastructure!". Similarly, companies have ended up trying to sue their CA to block an inconvenient revocation.
Most of those have luckily been due to small administrative errors, but it has painfully shown that the industry is institutionally incapable of setting up proper renewal processes.
The solution is automated renewal as you can't make that too complicated, and by shortening the cert validity they are trying to make manual renewal too painful to keep around. After all, you can't set up a two-months-long process if you need to renew every 30 days!
It's so annoying. Eventually we will get to the point that every connection will have its own unique certificate, and so any compromised CA will be able to be “tapped” for a particular target without anybody else being able to compare certs and figure it out.
it seems like all this infrastructure could be replaced by a DNS TXT record with a public key that browsers could use to check the cert sent from the web server. A web server would load a self-signed cert (or whatever cert they wanted), and put the cert's public key into a DNS record for that hostname. Every visit to a website would need two lookups, one for address and one for key. It puts control back into the hands of the domain owners and eliminates the need for letsencrypt.
I'm not sure what that would solve. You would still need some central entity to sign the DNS TXT record, to ensure that the HTTPS client does not use a tampered DNS TXT record.
stavros|2 months ago
It's hard to overstate just how much LE changed things. They made TLS the default, so much that you didn't have to keep unencrypted HTTP around any more. Kudos.
kragen|2 months ago
Vinnl|2 months ago
(I do work at Mozilla now, but this predates me. Still think it's one of its most significant (and sadly often overlooked) contributions though.)
1vuio0pswjnm7|2 months ago
LE allowed more sites to get certificates. This has obvious benefits for e-commerce, for example
But so-called "tech" companies, e.g., "Big Tech", have, since before and after LE was started, continued to perform the largest mass scale intentional erosion of privacy in human history
The exfiltrated data is encrypted in transit using TLS. This may prevent ISPs or other passive network observers from competing with the so-called "tech" companies in the data collection, surveillance and ad services business
Arguably the use of TLS certificates increases privacy from ISPs or other passive network observers, but it does not increase privacy from so-called "tech" companies, who are perhaps the greatest threat to privacy that computer users face. Their "business model" depends on violating privacy norms
And, in fact, commercial CA certificates as pre-installed in browsers and required on the www ("WebPKI") effectively obstructs computer users from monitoring their own egress traffic in real-time. Hence corporations and other computer users must work around "WebPKI" to perform "TLS inspection"
M
ACCount37|2 months ago
unknown|2 months ago
[deleted]
gorgoiler|2 months ago
Sorry to everyone else who was listening in on the wire. Come back with a warrant, I guess?!
simonw|2 months ago
eimrine|2 months ago
dust42|2 months ago
For example the cookies of the NYT:
There is no way to escape any of this unless you spend several hours per week to click through these dialogs and to adjust adblockers.And even if you block all cookies, ever-cookies and fingerprinting, then there are still cloudflare, amazon, gcp and azure who know your cross-site visits.
The NSA is no longer listening because there is TLS everywhere? Sure, and the earth is flat.
mqus|2 months ago
woodruffw|2 months ago
1vuio0pswjnm7|2 months ago
I read NYT with no cookies, no Javascript and no images. Only the Host, User Agent (googlebot) and Connection headers are sent. TLS forward proxy sends requests over internet, not browser. No SNI. No meaningful "fingerprint" for advertising
This only requires accessing a single IP address used by NYT. No "vendors"
TLS is monitored on the network I own. By me
I inspect all TLS traffic. Otherwise connection fails
phantasmish|2 months ago
I’d be very surprised if they haven’t had several of the root trust entities compromised from day one. I wouldn’t rely on TLS with any of the typical widely-deployed trust chains for any secrecy at all if your opponent is US intelligence.
Y_Y|2 months ago
Otherwise I find it a scourge, particularly when I want to run https over a private network, but browsers have a shitfit because I didn't publicly announce my internal hosts.
There's plenty of traffic that has no need to be encrypted, and where not much privacy is added since the DNS queries are already leaked (as well as what the site operator and their many "partners" can gather).
I'm glad you can get free certs from Let's Encrypt, but I hate that https has become mandatory.
gerdesj|2 months ago
I don't recall the exact details but it was basically buggered - short key length. Long enough to challenge a 80386 Beowulf cluster but no match for whatever was humming away in a very well funded machine room.
You could still play with all the other exciting dials and knobs, SANs and so on but in the end it was pretty worthless.
tiagod|2 months ago
kragen|2 months ago
wakawaka28|2 months ago
neilv|2 months ago
(Seriously: I strongly suspect that Let's Encrypt's ISRG are the good guys. But a security mindset should make you question everything, and recognize when you're taking something on faith, or taking a risk, so that it's a conscious decision, and you can re-evaluate it when priorities change.)
dbt00|2 months ago
RiverCrochet|2 months ago
The actual communication is secured by a public/private keypair which is separate from the CA certificate.
Browsers have a set of certificates "pre-accepted", these are the default root certificates. There have been issues with some of them over time (e.g. DigiNotar) and they hav changed over time. If you hear of someone speaking about the "CA cartel" this is what they mean.
So a compromised CA can make you think you are talking to someone, like your bank, when you are not. But it doesn't enable snooping on traffic on the wire.
A CA can protect from this compromise by keeping the root private key entirely offline and signing a couple intermediate CA certificates. Then, if one of those intermediate CAs gets compromised, it can be revoked and a new intermediate CA created. You as a user of the CA can't do much though-either you choose to trust it (or delegate that trust) or don't.
You can create your own self-signed root CA certificates and client/server certificates signed by that CA fairly easily. But you then have to add the root CA as a trusted certificate into every device you want to use it, including those of your friends, employees, etc. This isn't quite as bad as it sounds, the last time I checked even phones would install a new root CA certificate if you opened a .crt file, and deploying CA certificates via Microsoft Group Policy is a thing.
venturecruelty|2 months ago
throw0101a|2 months ago
* https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_...
tialaramex|2 months ago
See, SCEP assumes that Bob trusts Alice to make certificates. Alice uses the SCEP server provided by Bob, but she can make any certificate that Bob allows. If she wants to make a certificate claiming she's the US Department of Education, or Hacker News, or Tesco supermarkets, she can do that. For your private Intranet that's probably fine, Alice is head of Cyber Security, she issues certificate according to local rules, OK.
But for the public web we have rules about who we should issue certificates to, and these ultimately boil down to we want to issue certificates only to the people who actually control the name they're getting a certificate for. Historically this had once been extremely hard core (in the mid-1990s when SSL was new) but a race to the bottom ensued and it had become basically "Do you have working email for that domain?" and sometimes not even that.
So in parallel with Let's Encrypt, work happened to drag all the trusted certificate issuers to new rules called the "Ten Blessed Methods" which listed (initially ten) ways you could be sure that this subscriber is allowed a certificate for news.ycombinator.com and so if you want to do so you're allowed to issue that certificate.
Several ACME kinds of Proof of Control are actually directly reflected in the Ten Blessed Methods, and gradually the manual options have been deprecated and more stuff moves to ACME.
e.g. "3.2.2.4.19 Agreed‑Upon Change to Website ‑ ACME" is a specific method which is how your cheesiest "Let's Encrypt in a box" type software tends to work, where we prove we control www.some.example by literally just changing a page on www.some.example in a specific way when requested and that's part of the ACME specification so it can be done automatically without a human in the loop.
kuil009|2 months ago
dorianniemiec|2 months ago
abhashanand1501|2 months ago
crote|2 months ago
If a cert has to be renewed once every 3 years, plenty of companies will build an extremely complicated bureaucratic dance around the process.
In the past this has resulted in CAs saying "something went wrong, and we should revoke, but Bank X is in a Holiday Freeze and won't be able to rotate any time in the next two months, and they are Critical Infrastructure!". Similarly, companies have ended up trying to sue their CA to block an inconvenient revocation.
Most of those have luckily been due to small administrative errors, but it has painfully shown that the industry is institutionally incapable of setting up proper renewal processes.
The solution is automated renewal as you can't make that too complicated, and by shortening the cert validity they are trying to make manual renewal too painful to keep around. After all, you can't set up a two-months-long process if you need to renew every 30 days!
figmert|2 months ago
- [0] https://letsencrypt.org/2025/12/02/from-90-to-45
cortesoft|2 months ago
Tl;dr is to limit damage from leaked certs and to encourage automation.
pastel8739|2 months ago
eimrine|2 months ago
Lammy|2 months ago
donpdonp|2 months ago
akovaski|2 months ago
ryangibb|2 months ago
There's a TLSA resource record for certificates instead of a TXT encoding.
As far as I know no major browser supports it, and adoption is hindered by DNSSEC adoption.
pennomi|2 months ago
1vuio0pswjnm7|2 months ago
RagnarD|2 months ago
a96|2 months ago
(There's dozens of us!)
eduction|2 months ago
It’s bizarre. There is a photo at the top, no name, no site title. No about page. Extremely untrustworthy.
ThomasMidgley|2 months ago
Scroll down to the footer--> click on "Homepage"
Then you will get to his homepage: https://www.brocas.org/