> Not everything needs to be encrypted. If I'm serving static webpages the only thing I might want to log is the which IPs visited at what time of day.
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.
If you are frequently using networks you suspect to be hostile, wouldn't you L2VPN your traffic back to a trusted exit point regardless? HTTP/HTTPS is likely only part of the information your computer is providing to said hostile networks. Worrying about the encryption of plain text pages seems to be like worrying about a stain on the couch whilst the house is on fire.
* 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.
Where does logging enter into it? To my understanding, serving traffic over HTTPS doesn't require you to do any additional logging (or any logging at all).
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.
What example would you have of an ISP or third-party injecting an ad or tracker within the HTTP response? I've certainly seen the DNS query hijacking and while HTTPS will encrypt the transmission, at the ISP level they already have your DNS query and src/dst IP address. Even with HTTPS based on session data it wouldn't be difficult label Netflix/Youtube traffic patterns.
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 registrar level: the .tk registrar was (in)famous for injecting both ads and random JS into websites that were hosted on domains registered against it.
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.
> At the registrar level: the .tk registrar was (in)famous for injecting both ads and random JS into websites that were hosted on domains registered against it.
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?
Unless I'm misunderstanding, I think that's kind of orthogonal to the question of encrypted transit. Plenty of services that expose only HTTPS don't encrypt at rest (and vice versa).
I agree that not everything needs to be encrypted, but unfortunately a lot of people who browse the web are concerned when the browser complains that something is not secure.
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.
If everything that didn't _need_ encryption wasn't, then the use of encryption could be suspicious in itself. For my part I'm glad that we've moved to a mostly working system of encryption most things
The Web PKI is hierarchical, but it isn't particularly centralized (other than Let's Encrypt increasingly eating everyone else's lunch, which is probably a good thing).
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).
I'm sure there is some nuance to what someones static site is serving but someones blog doesn't need to be HTTPS. If they are offering downloads you can provide checksums or verify their data through other sources or contacting them out-of-band.
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.
The attack you are suggesting is not commensurate to the types of blogs and information that _need_ HTTPS.
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.
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.