* To serve content that can be accessed on networks using captive portals
* To serve content on localhost while developing
* To serve content on devices where setting up letsencrypt or other SSL is either too much of a hassle or not important
* To stand up a quick HTTP server on hacked servers
> * To serve content on devices where setting up letsencrypt or other SSL is either too much of a hassle or not important
This is my use case, serving homeserver stuff from a ".internal" domain, only accessible through WireGuard. I ain't gonna mess with a custom CA just for this.
If one of my devices gets compromised enough to be able to sniff network packets that pass through the WireGuard interface, I have bigger problems to worry about.
Sure: your web server doesn't need to care about the "S" part in the slightest in order for the web site to work over HTTPS.
Reverse proxies have existed for a very, very long time, you simply run a local HTTP server and you let the reverse proxy take care of https-to-and-from-the-WAN-side part. Even in dev context, that takes at most a few minutes to set up these days thanks to letsencrypt's certbot.
Others have offered good reasons but I'm going to offer another one, and I mean this seriously:
- Because I want to
Not everything is security sensitive. Some information is entirely public and has no need for encryption. While SSL is also provides protection against man in the middle attacks, which helps you to trust that the information you are reading has not been compromised and altered, this is also a security requirement that just doesn't exist in a lot of use cases.
So yeah, private internal networks where information security just isn't a requirement because the information is not at all sensitive and nothing bad will happen in a worst case scenario ... don't force things on people that don't require those things.
I can sort of understand the rationale for web browsers pushing encryption for public websites, with the amount of ecommerce that happens in current year. But if your use case doesn't fall into that bucket, and if you've done your own risk analysis and came to the conclusion that you don't need encryption for what you're doing because nothing bad can possibly happen then there's no need to jump through the hassle of setting up certificates.