I get that. I understand why viewing http is insecure, I dont understand why serving it is insecure.
Apparently this rubs people the wrong way. I get it, run Lets Encrypt and certbot blah blah, but if I am hosting an ESP32 in my house for a hobby project, I running HTTP on the LAN.
> I get that. I understand why viewing http is insecure, I dont understand why serving it is insecure.
Presumably you are serving that content so it can be consumed no? It's not like your consumers can consume https if you only serve http. But yeah I suppose if you are serving read-only content and don't give a shit about what happens client side, there's a lot less reason for https.
Serving data via http is insecure because that data can be intercepted, read and modified.
If it's entirely public data then there's no security risk to the server. The security benefit is for the clients, so unless you hate your users you should use encryption even for totally public static data.
> I understand why viewing http is insecure, I dont understand why serving it is insecure.
People are assuming you want others to be able to see want you are serving. In such case, the server is the only one who can secure the transmission to prevent MITM. The viewer cannot reach over and add in https into the request to prevent their ISP from injecting ads (or other kinds of MITM changes).
You can view pure HTTP website through VPN. It basically encrypted tunnel between you and VPN server through your ISP. So your ISP couldn't try to interject the encrypted connection.
However, your browser might prevent you from connecting to http due to strict https only policy. My browser will stop any connection to http page and throw up a warning.
Apparently this rubs people the wrong way. I get it, run Lets Encrypt and certbot blah blah, but if I am hosting an ESP32 in my house for a hobby project, I running HTTP on the LAN.