In what way is requiring encryption security theatre?
As a frequent user of public WiFi (mostly at coffee shops, airports, etc.), I prefer that every page is encrypted so that nobody can MITM me/tamper with what I see in my browser, even on plain text pages.
* Is using HTTPS enough on an insecure network? Should one also be using a VPN?
* Would end-users see a benefit from HTTPS on simple/plaintext sites?
> HTTP/HTTPS is likely only part of the information your computer is providing to said hostile networks.
What other non-encrypted information might a normal person's computer be communicating?
I understand that VPNs do improve privacy. Privacy is moderately important to me, but I don't think it's important enough for me to use a VPN.
There are also occasional vulnerabilities in TLS/SSL/HTTPS but... what can I really do about that? Even a VPN might establish its session with those technologies.
> wouldn't you L2VPN your traffic back to a trusted exit point regardless?
It's reasonable to expect someone technical like myself to do this, and maybe I am really just playing loose with my security. But, nobody outside of the tech community is even thinking about this. 99% of people are happy using whatever WiFi is free and aren't going to question its security.
So, using HTTPS for "simple" sites is still beneficial since you will be making your content more secure for less technical users who might be on insecure networks.
The point about static webpages would be a potentially good one in a world where ISPs and other Internet middlemen are honest and transparent actors, but this has so far proven not to be the case. I think it's in everyone's interest for your static content to reach my browser without ads or tracking mechanisms being injected by a third party.
Do you also have any reference to what exactly the collected data is useful for? I could see an ISP selling traffic data for a zip or area but they would already have that based on your billing address.
At the ISP level: I had a Spanish ISP attempt SSL stripping on me a few weeks ago.
> Do you also have any reference to what exactly the collected data is useful for? I could see an ISP selling traffic data for a zip or area but they would already have that based on your billing address.
The goal is always more (and more precise) data points. Being able to run JS on the same origin as the request is more valuable than just the rough GeoIP data the ISP already has.
I did a google search for domain hijacking, ad injection, javascript and while it does look like .tk domains had/have this issue it doesn't necessarily point to the registrar. After all they are offering free domain registration which is going to get abused. Its also not surprising when their own website doesn't use HTTPS, however their mission statement isn't about security on the Internet.
> The goal is always more (and more precise) data points. Being able to run JS on the same origin as the request is more valuable than just the rough GeoIP data the ISP already has.
But isn't this what Google, Bing, Amazon, Alibaba, already do when they fingerprint your device? They can't use just an IP addresses due to NAT so they collect unique characteristics to your specific device. My question was more so if advertisers can already get down to the device level when you visit their site, what is the ISP's motivation if their data won't be as unique or specific? or maybe a better question is what organizations would be buying the "less" specific data that an ISP could get from your session data?
From the browser maker's side, how does a browser know whether something should or should not be secured? They have clearly taken a more aggressive approach to inform users what is going on within the underlying protocol. While I do agree that not everything needs to be encrypted, I also agree that the user should know what is or is not happening under the hood.
But in terms of actual failure points: if you're initiating a connection over HTTPS, then the only way an attacker can MITM you is by convincing a CA to incorrectly issue them a certificate for that domain. That's why Chrome and Safari monitor certificate transparency logs, and why website operations should also generally monitor the logs (to look for evidence of misissuance on their own domains).
For a commercial service or if I was handling people's credentials I'd use something more robust.
Anything that needs some form of validation from any site should be verifiable in multiple ways. Just because they have HTTPS doesn't mean the provided information or data is automatically correct.
If you are operating at a level where your personal blog can have all possible transit paths compromised by a third-party such that they are hosting some or all resources that you provide for download, modifying them and producing new checksums then you have bigger problems than a blog that doesn't have HTTPS. You would also at that point consider using someone else's platform that will absorb or actively be motivated to thwart these exact scenarios. Not to say that always works out[1].
Additionally your concern of checksums being compromised can easily be thwarted by hosting packages on github, gitlab, bitbucket, pastebin, or a google groups mailing list. All of which still don't require your blog to have HTTPS. You don't have to manage getting your own certificate, paying for yearly renewals or setup any auto-90-day let's encrypt auto-bot.
Great grandma's cookbook recipes on a blog don't need HTTPS.
[1] https://www.zdnet.com/article/krebs-on-security-booted-off-a...