Why I won’t use Let’s Encrypt | Hacker News Reader

Why I won’t use Let’s Encrypt

stargrave.org

16 pointsstargrave16 comments

The argument that this person makes from what I can gather is I should not redirect people to https since their hosting company is not trustable by design of holding said keys and second that who am I to impose encryption on others who should be aware of their own follies by using said compromised keys. This is a terrible post to make it on Hacker News as the straw men arguments here are exactly what harms individual users based on the ignorance of the service holder. Fine that this is his choice but also fine that browsers make it explicitly clear that the site being used is a potential security threat. Making excuses for why you should not have encryption based on your biases against the security itself because your provider "may" have access to your keys and you don't trust them is a bad excuse. If indeed you truly distrusted your provider than find another that is more trustworthy. If you cannot then you should self host but it doesn't get you off the hook from providing secure services to your users. In fact it puts you more on the hook for it. If you do not trust yourself which is what is also lumped in with the argument of not trusting VPS provider you have bigger problems and should probably not be participating in this eco system if you cannot trust yourself.

> find another [provider] that is more trustworthy. If you cannot then you should self host ... it doesn't get you off the hook from providing secure services to your users.

You seem to have missed the existence of the HTTPS version of the page

I did miss the existence of the HTTPS version of the page but his opinion is still flawed by saying that he doesn't believe in it because he doesn't control it, yet he could by self hosting and his argument would either be mute by self-hosting or he himself is not even trustworthy to himself.

> his argument would either be mute

It’s “moot” by the way.

(A term who’s etymology goes back a very long way: https://www.theguardian.com/media/mind-your-language/2015/ja... )

> So in conclusion: [...] LE is definitely a NOBUS.

This sounds a lot like a conspiracy theory and I don't see in the article any explanation how that's relevant or possible.

LE doesn't force you to add CAA DNS records. Furthermore, you have CAs in your browser/machine that are far more sketchy than LE in the first place.

I think the article suffers from a clear point that I can put my finger on and say "oh yeah this is why LE is bad", in fact I don't see any points supporting that in a solid way. The article could be 1/5th the length and still achieve the same result.

> I think the article suffers from a clear point that I can put my finger on

He doesn't trust LE not to hand over a mitm certificate to some us american three letter agency and therefor refuses to use it.

> "LE is definitely a NOBUS" sounds a lot like a conspiracy theory

It sure does.

> you have CAs in your browser/machine that are far more sketchy

LE is in the focus of the headline, because people keep bringing it up to him. That is in the first paragraph. People complain about their browsers having trust issues with his webserver, and then go karen and suggest he uses LE, instead of establishing trust between the endpoints.

> LE doesn't force you to add CAA DNS records.

That you seem to misunderstand. The large selection of sketchy CAs the browser trusts are the reason why webmasters should use CAA DNS records. His page has both a TLS certificate and a CAA record, but the CA that issued it and is named there is not trusted by the browser vendors.

> He doesn't trust LE not to hand over a mitm certificate to some us american three letter agency and therefor refuses to use it.

The flaw in this logic is that LE could do that just as easily whether or not you use them for your legitimate certificate. And if you're worried about things like that, running insecure HTTP instead is about the worst thing you could do.

yeah you are right, that can't be it. Maybe the core point is that he considers the whole browser vendor based pki to be nonsense and refuses to partake, offering a self signed certificate instead. He probably memorized the key fingerprint and can verify it in person. The core point might be that those who want him to use LE barely care enough to make their browser not show warnings, they don't actually care about establishing trust.

I agree with you here there are many holes in this post that make it hard to take this person seriously beyond a conspiracy theorist who refuses to take responsibility of keys fully themselves and makes an extension argument that indeed they are also not to be trusted. This sounds like a very confused individual who needs to be told that their theories are flawed or at the very least that their lack of sense of responsibly is the exact reason why they should not be participating in being a provider of services/content.

You should use my login form without encryption based on my misunderstanding of what https is used for is not an excuse dammit!

Conspiracy theories aside, there are free non-US based ACME providers too.

that sounds even worse..

> My tarballs and Git tags are always signed with OpenPGP key

A key whose public component and fingerprint you serve over unencrypted HTTP too, meaning it doesn’t actually give any extra protection against a MITM.

i really don't understand this logic, taking the option of no security at all vs possibly flawed. it's like not locking your front door because a thief could just break in through a window.

To say "the juice is not worth the squeeze" may make sense in some contexts.

There isn't any perfect security. Who knows what microcode is really running at the chipset level, and how confident are we that it's bulletproof?

LE seems a decent approach for most uses. You can fret state actors all day, but if someone with acres of hardware and legal muscle wants a piece of you...

This guy is loopy.

I use Let’s Encrypt so that my users don’t get a security warning. That’s all. It’s worth it just for that.

> First of all, statements about lack of HTTPS are just completely plain dumb: try to explicitly tell your computer that you desire using HTTPS protocol, by replacing http:// with https:// in URLs.

That just gives a scary error, since the site's certificate is signed by "ca.cypherpunks.ru" instead of anyone trustworthy. And even if that did work, users shouldn't have to do it themselves.

> Next awful thing is that many people tend to confuse encryption and authentication of the endpoint (my websites in current case). With HTTPS you will definitely get good working encryption. Period. HTTPS clients generally complain about inability to authenticate the endpoint, but they won’t forbid using encryption. What people want for? Encryption? Then enable it by pointing to https://!

We want encryption and authentication. With just encryption, it's trivial for an active MITM to decrypt the traffic.

> I can not set up TLS on VPS, because its hosting company obviously will have access to all of its internals, including TLS private keys.

So?

> If I give TLS private keys to the hosting company, then what is the point of using TLS and lying that it can authenticate the endpoint domain?

Is the argument here really that you should never use TLS except on bare-metal servers under your physical control?

> Second reason is that it is not my responsibility to impose user the desired security protocol usage.

Fine, don't force it then. Keep insecure HTTP too, but at least set up HTTPS properly so that people who do want it can use it.

> Possibly there is already IPsec transport session, transparently securing the link.

No, there definitely isn't, since one end of it would have to be on his server for it to be secure, and if that were the case then he'd know about it.

> There is no reason for me to spend my money paying one of chosen CAs, because any of hundreds CAs beside can issue "valid" certificate for MitM-ing connections.

There's no reason to reduce the number of attackers from "literally everyone" to "a few heavily-audited CAs"?

> So what I am paying for?

Wait, I thought this article was called "Why I won’t use Let's Encrypt", and Let's Encrypt is free.

> Some browsers used OCSP, that literally leaks your intentions about visiting different entities to third-parties in real time.

Unless you're visiting a site on a big CDN like Cloudflare, and using both DNS-over-HTTPS and TLS eCH, you're leaking this anyway. Plus, OCSP stapling already exists just to close this leak.

> Google decided that all CAs have to use Certificate Transparency technology. Apple decided that certificate’s validity can not long more than ~400 days. From X.509’s point of view your certificate can be pretty fully valid, but not from Google/Apple one.

Won't CAs not issue you certificates that don't meet Google and Apple's requirements anymore? So doesn't that make this irrelevant?

> Very short-lived certificates and the fact that most ACME-clients create new keypair during each renewal, heavily complicates ability to use any kind of pinning. I visit many sites once per month – and it means that every time I get new public key, making pinning useless. LE tells that it is for limiting the damage from possible key compromising. Yeah, sure. However at least you are allowed not to generate new key pair.

Even if this were a legitimate concern, since you can just pass --reuse-key to certbot for your own site, this isn't a reason to not use LE.

> LE is clearly a NOBUS project. But do you remember that any of CA authorities imported in OS can MitM my domains anyway (by definition)? Well, partly you can prevent that for some software by using CAA DNS records, where you explicitly tell which CA authorities are authorized to issue certificates for given domains. Specifying LE in CAA means that I authorize noone to issue certificates for my domains, except for US-based forces. That is something I will never do, being the citizen of completely independent jurisdiction. I am not a traitor.

CAA doesn't protect you in the slightest against malicious CAs. It's the CA's responsibility alone to check CAA, and if they ignore it and issue a certificate anyway, everything will still trust the certificate. And it's absurd to think using CAA would make you a traitor.

> And there is another inconvenience of LE usage for me: they can easily revoke all certificates and prohibit usage at any time, because they have to comply with US-local policies on restrictions to sanctioned countries/regions. There were many occasions when ordinary programmers/users were banned on US-based services (like GitHub) just for visiting Iran or Crimea region. I visited several sanctioned countries and regions many times so far.

If you're worried about that, then just use a different ACME CA. It's still not a reason to use insecure HTTP. And I'd like to see evidence of a single person being banned from GitHub just for visiting Crimea once.

Reply on news.ycombinator.com