LetsEncrypt is great and I am really glad someone stepped up to create a mostly not evil non-profit cert authority. But everyone using LE is very bad for the health of the internet. It provides nearly a single point of failure for government/political interefence, technical failure, and failure due to corruption from money and scale internally.
Putting certs in DNS with DNSSEC authenticating them might be a more robust design overall, and would eliminate a lot of what is bad about HTTPS-everywhere (namely that LE trusts DNS to begin with, so doesn't add much to the web of trust, and that certificate issuance would be much more straightforward and automated from your TLD).
Unfortunately I have to disagree with you about the end of HTTP. ISPs have historically proven that they can't be trusted (NXDOMAIN interception, ad replacement/injection, DPI) and so for a non-negligable fraction of the world HTTPS (and DNSSEC or similar, although not enough people realize it yet) are a necessity.
I don't see alternative options except perhaps onion routing everywhere, but that only moves the goalposts to exit nodes without HTTPS and a PKI.
Another possibility for securing the existing PKI is to extend support for Name Constraints so that root CAs are only given authority to issue for subsets of domains, and finally making TLS only trust the most specific root CA for a given domain, e.g. if a TLS implementation has a trusted root CA with a Name Constraint of .example.com then it should not accept a certificate chain for anything under example.com from another root CA, and vice versa that root CA could not sign certificates for domains not under example.com. This would allow sites with high security needs to get their own CAs accepted by browsers, and allow breaking root CAs up by TLD which would match DNSSEC.
A normal user is in roughly the same situation with and without CAA; is a particular certificate trustworthy? Only trusted root CAs and CRLs can answer the question. CAA is only cryptographically secure with DNSSEC, and transparency reports give at least as much auditability.
You can say this when ISPs stop MITMing ads into documents served over HTTP.
A site I developed was being critiqued by a fellow director. They looked at the HTML and didn't like the poorly written advertising and analytics Javascript near the start of it.
But wait! What advertising and analytics? I didn't add that sort of junk.
It took us a few rounds of me defending my design decisions and not understanding what their problem with it was, and them becoming suspicious of me, before we figured out they were looking at Javascript inserted by their ISP in real-time into the site's HTML. Not something I wrote. We were viewing different HTML because of that.
That was 6 years ago. One more reason to switch to HTTPS, even for public, static content.
The problem here is not in HTTP. HTTP allows anyone and everyone to easily host and view each other's websites. Yes, ISP can interfere but that's not something anyone else can do in a targeted way.
The benefits far outweigh the downsides in most cases. You might have a business/profit motive to disable HTTP and that's fine. But most cases are not profit motivated.
No, it was a community group non-profit (non-profits have directors too!) and the site was a static site with public information and no tracking. Exactly the sort of friendly hobbyist site you are probably thinking should use HTTP. I was an unpaid volunteer, and the group did not pay for hosting.
> The benefits far outweigh the downsides in most cases
There were no identifiable benefits to HTTP or downsides to HTTPS for us. The switch was almost trivial. The ISP issue hurried the conversion though.
> I've tunneled to various VPSes for web surfing.
If you have to use a VPS to use HTTP safely, with its extra cost and latency, why are you down on HTTPS? Having to use a VPS with your HTTP is basically the same thing as HTTPS but with higher cost, higher latency and more security centralisation.
That's not a positive advert for HTTP, if you feel you have to use a VPS to use it safely.
If applied, they'd stop and HTTP would be safe for static sites.
I'd be interested to hear more about this, care to elaborate?
So now we have sites abandoning HTTP entirely and only having HTTPS. So this encourages browsers like Firefox to start enabling things like HTTPS only in their browsers by default. It encourages putting up scaremongering warnings of danger on HTTP sites like HTTPS self-signed certs get (which killed off self signed sites).
So now browsers are beginning to refuse to show HTTP and the web admins are putting up servers that refuse to serve HTTP. That means in the near future unless you can get a cert authority approval (forever) you'll be unable to host a visitable website (ie, get a TLS cert from an authority) and unable to visit most websites that don't play the cert game unless you modify your browser.
Human people cannot be cert authorities. Only corporations can. These two trends towards HTTPS only, on client and server, lead inevitably towards a situation where everywhere is in a handful of cert authority chains and things become easily controlled, or accidentally broken, due to that centralization.
Cloudflare though, we should all talk about more...