Let’s not encrypt (2019) | Hacker News Reader

Let’s not encrypt (2019)

michael.orlitzky.com

45 pointsAndroidKitKat94 comments

I'm always baffled by people arguing that we shouldn't use HTTPS. Have these people forgotten the times when mobile providers would "optimize" images (=compress them to death) or even insert advertisements? Or the times when simply being on the same network as someone with alterior motives could lead to your credentials being stolen?

I get it, certificates are hard, but having free certificates by Letsencrypt has probably been one of the most beneficial things that happened to the Internet in the last 10 years. If someone doesn't like it, please put in the work to come up with a better solution, not arguing for an even worse solution.

The author of this article doesn't propose anything workable. Mentioning SSH is ridiculous, it's not meant to access servers you don't know. Also, I have seen more than a few sysadmins who would easily be tripped up by a MITM because they'd just wipe their know hosts file at the first sign of trouble. And these are TRAINED people.

LetsEncrypt is FANTASTIC !

I think you're conflating two things.

Protecting against modification of data in-transit can be done without encryption. Signing the clear-text content allows the receiver to verify if the data is original. Encrypting hides the content from middle parties.

In the age of interest-based advertising is it really reasonable to suggest that we should let our network provider see every single website and subpage we visit?

This is really my problem with the "don't encrypt anything static" argument. I don't encrypt for security (or at least not primarily; I am not under the illusion that encryption makes my data unassailable) but for privacy.

There is a big difference between every jump between me and example.com seeing "example.com" or "example.com/so-you-think-you-might-be-heading-for-divorce.html" (just an example; I am happily married, in case my wife ever sees this).

Signing clear-text content requires only slightly less infrastructure than encrypting it, for a less useful result. I don't want every party in between me and the destination server to be able to see the contents of my HTTP requests, even for static pages.

HTTPS is what makes the difference between an ISP being able to see that Alice is on WebMD and an ISP being able to see that Alice thinks she has a specific embarrassing illness.

Or even worse, Alice was just curious because of a conversation that happened and now her advertising profile will mark her as an insurance risk.

That's not what the article is suggesting.

> My medical opinion: if it hurts, maybe you should stop doing it.

Which part of this is not suggesting we should stop using HTTPS?

I interpreted that as meaning stop using LE, not stop using HTTPS. But in context, I see it can be reasonably interpreted either way.

It doesn't matter which CA one is using as long as there is a CA that's freely available to anyone. The article makes very questionable suggestions such as this:

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

I would interpret this as the author arguing against the entire CA system.

The days of plain HTTP were amazing, from the point of view of a teenage hacker that hung out at the public library of a college town.

At one point when Facebook started becoming popular, I had a script on my laptop that would grab session cookies from other people on the network and post things to the victims' facebook status like "I'm using unsecured wifi at the public library and I like to sniff butts"!

Learning that stuff taught me a lot about network security, and left me with a wariness of trusting networks that I don't control that I still keep close to heart long into my career.

The days of Firesheep

TLS solves two problems, but was originally designed to solve three. The author seems to be annoyed that it does not solve the third problem.

TLS (or SSL, really) was designed to solve trusted authentication - that you could be sure the website that responded to your request was your bank. The idea was that a manual review from an authority would verify that the owner of certificate x was the "real" y, for some definition of x, y, real and authority.

It does not solve that problem, I agree.

It does, however, solve two other problems: The problem of message integrity - noone intercepted and changed this message between server and client; and the problem of eavesdropping - noone can read the message by observing the network traffic alone.

Now, of course, this all depends on the fact that the connection was setup correctly, and a man-in-the-middle attack that can redirect all the traffic for some domain to their own servers would possibly succeed. But that is quite a high bar! Modifying DNS or shaping network traffic in that way requires deep access, and is much, much harder than attacks with no SSL/TLS.

Has there been any known successful MITM attack with forged certificates since the introduction of CT? I am not aware of any.

Those two other problems that it does solve could be done in a less centralized way, couldn't they? E.g., add a record to DNS that contains a public key for the domain. Clients can grab that when they are grabbing the server IP address.

DNS is unexpected and easily modified.

That's not really any better than what we have now. In your model you need to have full trust in the DNS operator and that your DNS responses weren't MITM'd (which are still generally unencrypted!!).

In other words, you're just trading trusted CAs for trusted DNS operators.

We already have to place full trust in DNS operators—a rogue DNS operator could trivially get a LetsEncrypt cert for your domain and redirect your traffic to a different server that they control.

Sort of. Let’s Encrypt checks multiple DNS operators, so you’d need to compromise multiple from LE’s perspective.

Whereas putting the public key in DNS only requires compromising a user’s nearest DNS server. For example, in my home network I would be able to MITM any site that anyone using my DNS server, which DHCP will gladly hand out, attempts to connect to.

Edit: actually, I would be to MITM any unencrypted DNS lookup. So even if they didn’t use my DNS server, I could still alter the responses.

I didn't state it, but I was assuming that browsers would only use keys from DNS servers if they had used DNS over HTTPS to make sure they are talking to a DNS server that the user trusts.

And what if the request isn’t made via DoH (very few today are)? Do we just fallback to the existing Web PKI? If so we’d now have two systems to support until everything is migrated to DoH, which can very well be never.

Also, how do we know which certificate to use for DoH?

Ah, that makes sense! I thought you were talking about the root nameservers, I wasn't considering all the other DNS servers.

The author recommends TOFU as an alternative. TOFU is great until it isn't. Web servers do get hacked all the time (mostly thanks to Wordpress), and when they do, rotating any and all private keys is high on your action list (preferably through nuking the machine from the orbit).

The short expiration date on the certificate is specifically meant to address this problem. CRLs don't work, not even by principle - how often are you meant to refresh them? Who's volunteering to handle the load?

Which circles us back to the underpinning of the fundamental problem: DNS is insecure. If DNSSEC was to be the answer, where is it, 20 years in? Can we pretty please adopt DNSCurve instead already?

Exactly. GitHub recently illustrated why TOFU is non-optimal when they had to rotate their keys [0]. For weeks, everyone was re-trusting GitHub's keys and most of the advice out there just said to scrub the remembered key and re-trust whatever came up.

If that's how the technical users of GitHub were reacting, why would we try to make regular people keep track of trusted keys?

[0] https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-k...

> And, as always with the certificate authorities, a thousand murderous theocracies, advertising companies, and international spy organizations are allowed to impersonate you by design.

Certificate transparency has been required by chrome for new certificates (and sites that opted in) since 2018, and all older certificates expired by 2021 (because certificates have a maximum allowable lifetime). So this was dubious even at time of writing, and outright false today, for a large majority of users.

> Let's Encrypt isn't free to run, either. Their 2019 operating budget is 3.6 million U.S. dollars. Most of that is donated by… guess who? Your competitors.

Let's Encrypt has something like 80 sponsors listed. The vast majority of them are not, actually, competing with you. Even if some of them are, the nature of a non-profit funded by a wide range of sponsors just makes it a terrible way to attack someone.

> The certificates provide no security

Uh... it guarantees that the entity you're communicating with is the one with control over the web server you're trying to access.

The points about HTTP are worthless. Everyone's web traffic should be E2EE for everything. I don't understand someone arguing that it should be possible to spy on other people on your network.

While some of this article makes sense, it is full of exaggerations and outright lies.

If you want longer-lived certificates manually, don't use Let's Encrypt. Why pretend that no other issuer exists?

> You don't have to use certbot (...) you can renew certificates manually

Or use a different client? Do we pretend these don't exist, too? https://letsencrypt.org/docs/client-options/

> If you have a hundred websites, then on average that's four hundred renewals a year—more than one every day. Every single day. For the rest of your life.

Right, because you can't renew more than one on the same day? You can't do your 100 renewals and go on vacation for 90 days? Why not? That's just not how averages work.

> Normally, when a site changes URLs, you can use a redirect to send visitors to the new address. But, if the old address is HTTPS, that doesn't work: the old address will display a misleading security warning instead of redirecting.

That too is an outright fabrication. I just tried a 301 redirect from HTTPS to HTTP and it worked fine, on up-to-date Firefox, no security warning. Maybe the author promised to never get rid of TLS with a `Strict-Transport-Security` header? Don't do that?

> When you install a certificate with a three-month expiration date, you're saying “I want my website to break in three months unless I show up and tell it not to.”

Is that how you feel about permits, licenses, subscriptions? Fixed-time contractors? A "real engineer" wouldn't use anything time-limited?

> save the certificate permanently the first time you connect

That's the final recommendation? After the author concluded that "certificates provide no security" in the second paragraph because they might man-in-the-middle the challenge? Are we supposed to ignore that they might man-in-the-middle that first connection?

>> Normally, when a site changes URLs, you can use a redirect to send visitors to the new address. But, if the old address is HTTPS, that doesn't work: the old address will display a misleading security warning instead of redirecting.

> That too is an outright fabrication. I just tried a 301 redirect from HTTPS to HTTP and it worked fine, on up-to-date Firefox, no security warning. Maybe the author promised to never get rid of TLS with a `Strict-Transport-Security` header? Don't do that?

I think the author wants to be able to move a site by setting the old domain's DNS to point at the new site's server and have the server 301 all/old domains to the new domain. Which... you can still do, just with HTTPS in play you have to handle certs for any old domain(s) you're redirecting.

I think the true problem here is associating the word secure with https. It provides a false sense of security when the site served over https is a scam or phishing site, but very few non-technical users understand the difference.

While I don't agree with everything in the post, I still found it thought provoking. I'll still be serving my sites with HTTPS.

The really annoying thing is how browsers treat self-signed certificates as some dangerous thing, when it's really much safer (no MITM or eavesdropping) than http.

How would a browser know the difference between a self-signed certificate created by you and a self-signed certificate created by an attacker? You can create self-signed certificates on the fly based on the SNI.

Right, obviously self-signed is worse than a proper cert. The argument is that even self-signed is better than no encryption (plain insecure HTTP), but browsers treat it as worse. The idea gets raised every now and again that self-signed certs should be treated exactly like no cert at all - no lock in the address bar, but also no big massive warning page screaming that this page is insecure.

How does a self-signed certificate that hasn't been added to the browser as trusted, or signed by a trusted CA, guarantee anything? Save for additional network security measures anyone could intercept the connection and present you with their certificate to intercept traffic, just like with plain old HTTP.

The average user shouldn't be asked to trust a certificate either because they are incapable of making that decision. Technical people should know better and can be asked to add the certificate to their browser.

It doesn't guarantee anything, that's why I said it should show up the same as no cert. The only point is to break passive MITM attacks, which is still better than nothing.

Ah, I see what you mean. Well, the way things are going you'll have your wish as all HTTP-only sites will get a warning eventually.

It requires a significantly more sophisticated attacker, for one, as opposed to just opening wireshark on a public network. Either way, it's at least not as scary as unencrypted http.

> 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. If that sounds dumb, then good for you, because it is.

I'm a bit confused by this. I use Caddy, and Caddy doesn't run in root – and Caddy is able to handle automatic Let's Encrypt certificate renewal.

Why does certbot need root?

It doesn’t necessarily, people are just conditioned to using root for things that don’t necessarily need it because it’s easier.

I guess I'll just have to run anything that needs root in some sort of container.

certbot copies the file to be served as part of the challenge. It can optionally can modify your nginx config to use the cert once its obtained. I don't see why it needs root to do this, but you'd at least need permissions for it to read/write to the appropriate nginx & server folders.

certbot doesn't need root, it just writes to directories that are usually limited to root by default (`/etc/`, `/var/log/`, `/var/lib/`). And it needs some interaction with the web server to actually complete the challenge.

You can absolutely provide it with alternative paths and configure your web server to forward `/.well-known/acme-challenge/` to a non-root location.

The MITM observation isn't any more dangerous than Trust on First Use. The attacker would have to identify you as a target and set up their MITM before you got around to setting up your own cert. Sort of like an attacker compromising your SSH server before the first time you got around to connecting a client and trusting the key.

Yes, and this point is kinda nonsense since communication to letsencrypt‘s api is via https, and you trust the LE root since their cert is included in every new mainstream OS which got released after, i don’t know, 2019?

Thought-provoking. I didn't consider why LE is free (sponsored by Google and AWS) and that it can technically change that at any time. I'm still going to continue using HTTPS for now since it's my status quo, but I guess, for public websites, the choice to use HTTPS or not depends on whether or not one agrees that widespread HTTPS is vital to discourage ISP/government snooping.

I disagree with the TOFU recommendation, though. From my knowledge, it kinda works for SSH since you're mainly connecting to servers you control; not so much for the WWW. Anyone remember MonkeySphere? I also disagree with the 3-month criticism. I think LE has a good justification for it: usually, renewal is either automated or forgotten about, so a short timespan forces automation. The bomb analogy doesn't really make sense as certificate expiry serves a practical purpose unlike a bridge-bomb.

I found Lets Encrypt so convoluted that I would rather buy SSL certificates.

I guess I should explain my thoughts. Let's Encrypt places no value on long term stability. I believe long term stability a straight forward measure of reputation. Let's encrypt represents a technical solution meant to replace a simple concept. The technical solution appears needlessly complex considered other methods.

Everyone that uses letsencrypt has a cron installed to auto-renew. Certbot needs two permissions to work:

1. perform the necessary verification, of which there are many, placing a file on your website is just one possibility.

2. place the generated certificates in some location where the webserver can read them.

Neither of these steps requires root if you know what youre doing.

Unfortunately by this point is a losing battle, most techies have been conditioned to believe that serving unencrypted raw HTML, HTML which contains no confidential information in it, might as well make the Dark Forces of Evil win. "What if someone MITM-es your recipes blog?".

Of course, it just happens that this let's encrypt push puts even more power in the hands of Google, the owner of Chrome. I would have said something about that, too, but yesterday someone re-posted the HN guidelines and I'm not up for another fight with Google engineers comp-ed 600k and up, engineers who are very eager to anonymously defend their employer online.

> "What if someone MITM-es your recipes blog?"

You can alter the ingredients to be lethal.

I might bat an eye at "2 tbsp arsenic"

They can alter the page to ask for money, offer a free cooking companion app/keylogger, etc.

Confidentiality isn't the only thing TLS safeguards. Integrity is a big one too.

Some ISPs were injecting ads in all sites, sometime breaking them in the process. TLS put an end to it.

> The way you verify your identity to Let's Encrypt is the same as with other certificate authorities: you don't really. You place a file somewhere on your website, and they access that file over plain HTTP to verify that you own the website. The one attack that signed certificates are meant to prevent is a man-in-the-middle attack. 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.

Doesn't ssl handshake require knowing the private key?

Obtaining the initial certificate is somewhat vulnerable to MitM if the attacker can divert the verification request to a server under its control. Some countries (including Iran IIRC) went as far as using BGP announces to do that (which makes it very obvious).

Let's Encrypt uses Multi-Perspective Validation (https://letsencrypt.org/2020/02/19/multi-perspective-validat...) in order to protect from most interception of the DV request.

Yes, but SSL is not used for plain HTTP.

Also, I think you meant TLS but that is only used in HTTPS not HTTP.

No, he's specifically referencing the initial setup step of Let's Encrypt, where you don't have a valid HTTPS cert so Let's Encrypt has to connect to your server over HTTP, see here: https://letsencrypt.org/docs/challenge-types/

And yes, technically he's not wrong. Well, technically he is wrong, in that it wouldn't be a MITM attack, exactly, but if an attacker can intercept requests sent to your domain by LE and respond however they want, they can generate an LE cert for your domain, even if you're not using Let's Encrypt. That said, they can't intercept generation of the LE certificate - the HTTP request is just to prove that you've got enough control over the domain to justify issuing one.

Using HTTPS wouldn't prevent that. I'm actually not sure how you would prevent that, short of removing HTTP-01 from the spec and requiring DNSSEC and so on. EDIT: I see a sibling comment pointed out that Let's Encrypt are aware of this, and are using "multi-perspective validation" to make requests from multiple regions, making this attack much harder to pull off (but never impossible, I suspect): https://letsencrypt.org/2020/02/19/multi-perspective-validat...

OP keeps repeating tha Google is making money from certificates. I don't think Google sells certificates, and even if they do the revenue is insignificant for them. Does anybody know what OP may be referring to?

Yeah this was confusing to me. They both state that Google is making money from the certificate racket, while also suggesting that Google might come out with their own CA and kick out LE to corner the market. It's contradictory.

It was written back in 2019, but they were partially correct. Google did make their own CA (https://pki.goog), but they now also give certs out for free via ACME. And they didn't boot LE.

Not touched in three years, and full of FUD.

We should do better on HN.

Can't say I fully agree, but I definitely share the sentiment. Let's Encrypt is a nice hack, not a long-term solution. We need DANE.

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Even worse, HTTP/2 and HTTP/3 (and basically every new web technology) is only usable over HTTPS. I'm seriously starting to question the agenda behind this, this is not beneficial to the users in any way.

Self-signed certs should fine (if you validate them initially) but browsers make self-signed sites almost impossible to access, relying on Let's Encrypt or being subject to extortion is a shameful state for the web.

Also, what's with the ever-shrinking renewal periods? Why can't a certificate be valid for 10 years? They can revoke it anyway if it's been compromised or whatever.

CRLs are incredibly expensive to serve, and OCSP isn’t great either. Having short lived certificates makes it cheaper for let’s encrypt to serve the internet since the CRLs don’t need to be as large (you don’t need to maintain a list of compromised expired certificates in your CRL for example).

Has anyone explored using a technique like a Bloom filter or partial hash matching (like haveibeenpwned does) as a preliminary step for CRL lookups? You could do a cheap initial query, and if you get a negative, you're good. You only have to do the full expensive one if you get a positive, to ensure that it's a true positive. Which should be rare since most certs that are presented won't be revoked.

Honestly? I don't think it makes sense for us to continue down the path where the clients connect to the CA to verify status. While I trust most CAs (like LE), the less information a client has to expose to one the better.

https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...

> They can revoke it anyway if it's been compromised or whatever.

When have you last seen anyone revoke a Letsencrypt certificate? I haven't. Ever. I use Letsencrypt all the time and even I'd need to look up how to do it.

You seem to operate under the assumption that certificate revocation does anything on the web. In practice it is only useful in the presence of mandatory OCSP stapling. And mandatory it is not.

Software and web standards are quasi extensions of business policy as of late. It seems that the ones who require you access said sites via https+cert will gladly pivot foot and sell you said certificate when you realize you need it to unlock the full potential of the browser and thus your users eyeballs. Similar locked gardens lately can be seen in the form of Apple's app store. Not to say that secure, encrypted sites are not preferable but the lengths that unnamed parties have gone through to cripple things is not just circumstantial.

> Also, what's with the ever-shrinking renewal periods? Why can't a certificate be valid for 10 years?

Also, why can't a certificate be valid longer than the certificate(s) above it in the verification chain?

For code signing certificates that is how it works. When checking a given link in the chain for validity the time check is whether or not the upstream certificate was valid at the time the downstream certificate was signed.

It is analogous to how notarization works with physical documents. A notarized document does not cease to be notarized just because years later the Notary Public who notarized it retires lets their notary license expire.

For HTTPS certificates the check is that each certificate in the chain is valid now. In physical document terms it is like if when a Notary Public retires it invalidates all their past notarizations.

Should I be concerned if a payments processor or a SaaS business is using Lets Encrypt?

No. From a security point of view, LE is fine -- even superior to other methods if the service isn't on their game.

The valid issues with it aren't security-related in my opinion. Management issues like updating certs are more time-critical, of course, but if they get that wrong, the worst that will happen is the service won't be available for a bit.

Ok so you discover your SSL management process is broken much sooner with LesEncrypt vs the competitors. That sounds like an added-value.

As I said: "even superior to other methods if the service isn't on their game"

I have to agree. HTTPS everywhere is security circus...

I'm also not a fan of LE, for some (but not all) of the reasons stated here. I particularly hate the short cert lifetimes (that they intend to make even shorter).

CRL are a failure, OCSP can't scale, so to get some assurance that if the private key was compromised somewhat recently, it's either mandating OCSP stapling or shorter lived certs...

Why do you hate the short lifetimes?

Why can't OCSP scale? Doesn't stapling help a lot with that?

Stapling works, but is a lot more useful if it is mandatory (which it is not). OCSP as intended in the early 2000s where the client query the CA is a non starter, the hosting cost would be such that not only free certificates would end but the paying one would be much more expensive.

I think most people will find short lived certificates more convenient than mandatory OCSP stapling.

> Why do you hate the short lifetimes?

Because they require more frequent maintenance. That has to happen either manually or through automation. LE seems to think that automation means that short lifetimes aren't painful, but I disagree -- if for no other reason than that there are plenty of places where automation is not feasible.

Let's Encrypt isn't exactly hiding that it's only practical in the context of automation

From their FAQ (https://letsencrypt.org/docs/faq/):

What is the lifetime for Let’s Encrypt certificates? For how long are they valid?

Our certificates are valid for 90 days. You can read about why here.

There is no way to adjust this, there are no exceptions. We recommend automatically renewing your certificates every 60 days.

Right. I never claimed that LE was hiding this fact. I'm just saying that requirement is very problematic for me and makes LE a suboptimal solution for my purposes.

I agree with this. I use L.E. for a handful of hobby domains, and it seems every 3 months, something fails, and I have to ssh in and diagnose and re-run something and restart some processes. Yuck. I’d rather just get/configure certificates once, and not have to worry about them anymore.

This feels like software that deletes its own config file every three months, just to make you write a script that regenerates the config. Make-work. It would be great to have a button “I understand the risks, give me a 5 year certificate.”

What's your issue with short lifetimes?

I answered this in a different comment. TL;DR is that short lifetimes bring greater maintenance requirements, and automation is not always helpful.

You're rephrasing your claim, not providing any argument. If renewal is automated correctly, why would it bring more maintenance? When is automation not helpful?

If my automation is broken, I would rather find out sooner than later... or having to find out the previous guy set it up wrong. Wouldn't you?

My claim is that I have situations where automation is not feasible to implement, not that I have trouble correctly setting it up.

People are downvoting my comments here, no surprise, so I feel compelled to clarify: I am not saying that others shouldn't use LE, nor am I saying that LE is without value. I am acknowledging that LE is not a panacea and brings its own complications that have to be considered.

In my case, LE is not a solution that works for me. Instead, I buy the certs for my websites that are used by the general public, and run my own private CA with my own root cert that is used to mint certs for everything else.

I would love to hear more about your issue though. I have deployed LE in situations where I needed wildcard certs and didn't have access to the DNS server to set the challenge (literally a separate network) successfully. I have deployed it in situations where the DNS server doesn't even have an API at all.

I won't claim that it is always easy, but I really can't object to the short lifetime. I agree that the goal should be to automate this. After all, domain registrations aren't forever, you shouldn't be able to hold on to certificates to someone else's domain.

I'm certainly not saying I have a situation where it's impossible to do automation. Just that it's sometimes not feasible, in that it takes too much effort and introduces more points of potential failure. In other words, that it's more complex than just buying a cert with a longer lifetime and using that.

In my case, it's not a DNS issue but one of the systems themselves not having enough available resources to put the automation on, which means that I'd have to do the automation on another machine and either set up some sort of automated method of moving the certs to their ultimate destination or manually install them.

> domain registrations aren't forever

Technically true, but practically? The youngest domain name I have, I've had for over a decade. Most of my domain names are much older. They are, for all intents and purposes, permanent.

There's a lot of nonsense in TFA.

[2019]

Thanks for the reminder, fixed!

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

I guess? But they later state that SSH's trust on first use is the solution... which has the same problem. Am I connecting to the real bank website or a fake one? Who knows! But I'm going to trust it forever.

Additionally, most man-in-the-middle attacks occur on the client side (ex. some local network is compromised), which is still prevented here. You would need to man-in-the-middle from LE's perspective.

> “But you don't have to use certbot,” say the people who haven't thought very hard about it. And they're right: you always have options. You can renew certificates manually, but

Why the fuck did they link to the Youtube HQ shooting here? Anyway, they also link to a bunch of clients that don't do manual renewal.

> The entire certificate authority system is a for-profit scam. It imparts no security whatsoever. But Google gets its money, so it's happy.

I'm sorry, how is Google getting money from PKI? In the previous section they actually implied that Google might drop Let's Encrypt in order to have their own CA make money. So which one is it?

I know this was written in 2019, but since then Google has entered the market (https://pki.goog/), but they didn't boot Let's Encrypt. In fact, they adopted ACME and provide certificates for free as well. So they're still not making money from it.

> what to do about it > 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 author has no concept of the real-world. Prompting users to accept a certificate on first use is just going to cause them to always click "trust" since the other option will always break what they're trying to do. A website can then never rotate that certificate without breaking every user that visited their site before. So if the certificate does leak, someone now how boundless ability to MITM everyone that has visited the site, and anyone not MITM'd will now get a security error.

Overall this article constantly contradicts itself and merely presents out a poorly thought-out solution as the answer.

Reply on news.ycombinator.com