> 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 <a href="http://" rel="nofollow">http://</a> with <a href="https://" rel="nofollow">https://</a> in URLs.<p>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.<p>> 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 <a href="https://" rel="nofollow">https://</a>!<p>We want encryption and authentication. With just encryption, it's trivial for an active MITM to decrypt the traffic.<p>> 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.<p>So?<p>> 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?<p>Is the argument here really that you should never use TLS except on bare-metal servers under your physical control?<p>> Second reason is that it is not my responsibility to impose user the desired security protocol usage.<p>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.<p>> Possibly there is already IPsec transport session, transparently securing the link.<p>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.<p>> 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.<p>There's no reason to reduce the number of attackers from "literally everyone" to "a few heavily-audited CAs"?<p>> So what I am paying for?<p>Wait, I thought this article was called "Why I won’t use Let's Encrypt", and Let's Encrypt is free.<p>> Some browsers used OCSP, that literally leaks your intentions about visiting different entities to third-parties in real time.<p>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.<p>> 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.<p>Won't CAs not issue you certificates that don't meet Google and Apple's requirements anymore? So doesn't that make this irrelevant?<p>> 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.<p>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.<p>> 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.<p>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.<p>> 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.<p>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.