While your website might not contain anything interesting, leaving it on HTTP leaves the door open for an attacker to put something nefarious on there, which you wouldn't want even if the current content is low stakes.
It’s sad we can’t just encrypt the communication by setting up something in the server and that would be it.
You can? With any of Let's Encrypt's clients ( certbot, lego) of web servers that come with an ACME integration ( Caddy, Traefik).
I'm not sure that this is an avoidable problem. If your web browser would accept an unsigned certificate, then it's not really encrypted content. The router could intercept the relevant HTTPS request, connect to the self-signed server on its own accord and pass the data back to the client. All we're achieving there is the use of a few more CPU cycles.
Lets Encrypt gives you proof that at some point in the last 90 days, Lets Encrypt's routes, which you trust to be more secure than your own routes, were able to access this server (modulo pedantry). If this information is interesting to you, you need to distinguish between the occasions when you have some alternative means of trust from the majority case. Browser warning pages are an in-your-face but reasonable approach.
As a person who has a vague understanding of how PKI works and a relative ability to distinguish "I want to access this site now" from "I have a means of proving that I trust this key", I would appreciate it if I could say I trust this signer or do something like trivially set up an acme signer for my home network.[*] The browser's "permanently stop caring about trust for this site" isn't really one that I enjoy using (even the old fashioned option to "add a temporary exception" was better!), and a lot of software is becoming harder to use without TLS.
[*] ed to add: I mean I can, but it's matter of time and energy. I think Windows makes it relatively easy to add a new root key, and on Linux I guess it's a matter of doing all the stuff you do whenever you configure stuff. On Android I have no idea if it's possible or if I just have to trust exactly whoever it is that OnePlus trusts. I've seen tutorials for how to deal with some of this stuff, and I always filed it into the box of things to deal with when I got a round tuit. It's not so much the ability to deal with it, as the fact that it's a fair amount of work, needs to be repeated for several devices, needs to be repeated for new devices, may not be doable for all devices, and it's done so rarely that it's completely impossible to memorise and even if you could something has probably changed in the interim. In short, it's possible, but using HTTP is way easier despite the fact that sometimes you have to override defaults.
Not necessarily, you can use lego client with dns01 challenge. This is how I issue certificates for local services running with dnsmasq or hosts file.
Only if you're using the HTTP challenge, the DNS challenge is (IMO at least) much simpler, easier, doesn't require any services open to the internet so can work in a LAN, and can issue wildcard certs too.
If you use a webserver like Caddy as well, then your SSL certs are done automatically without you needing to do much of anything at all.
Either every box that wants to use SSL has to be capable of changing DNS settings, or you need a central box that generates secrets and securely transmits them to the servers.
I have domain names which I am authorised to serve content on, but not authorised to manipulate DNS for (but they're all exposed to the internet, so not relevant to the limitation - but probably the reason I overlooked the blindingly obvious solution)
SSL doesn't magically secure your servers, especially not if all you are doing is serving static HTML content and images.
All HTTPS really does is encrypt the HTTP traffic while it is in transit. The main reason this is important is because someone monitoring network traffic (for example, at the network switch) could theoretically see raw passwords and stuff being sent over the wire in plain text.
If your web site doesn't do anything with user names and passwords or form fields that accept some type of text that needs to be secured, then HTTPS isn't really doing jack shit for you (other than making visitors "feel" secure).
Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.
For those sites you mention, confidentiality and availability will not really be impacted by HTTPS.
But the integrity can be.
Case in point: See this comment https://news.ycombinator.com/item?id=27507826
To be clear, I'm very pro-SSL and have used LetsEncrypt for years on all my domains. I was just taking issue with the notion that someone's web server serving static content could be breached just because it didn't have an SSL cert.
Because unencrypted HTTP allows attackers to MITM the traffic, they can do things like put ads on your site, inject malware or bitcoin miners, or just replace your site completely. None of those affect you, the site owner, directly, but ìt subverts the purpose of your site and lowers the value and trustworthiness of your site to your visitors.
It’s a necessary level of defense but it is NOT sufficient- especially if you never check certificates.
Not just governments. I can get in my car and go to the three main shopping malls in my relatively large Portuguese city. I will very easily MITM a bunch of people there, no problem, using a variety of attacks. They won't realize that I'm now sucking all their traffic in and modifying it as I please.
After I've done that, if they visit any HTTP link, I can inject whatever I want there: crypto mining, download links to a modified/hacked version of their browser, social engineering attacks (phishing), cookie hijacking, etc. Notice how I can modify whatever HTTP page you have to link to websites you think are secure (banks, social media, websites), but that are modified (e.g. via sslstrip, or just by being similar-but-not-quite-the-same-hosts, etc)
Many months ago I went through this here: https://news.ycombinator.com/item?id=25123366
It should be a duty for all sysadmins to make sure their sites are HTTPS. Sure, if they're only in an intranet, HTTPS is likely overkill. But any publicly hosted website should be forced to be HTTPS.
One single HTTP website leaves a person vulnerable to millions of attacks. Many of these are still present on the web with HTTPS -- but at least then they'll typically be done by the people running the HTTPS site, not by someone in the middle.