The worst that can happen is malware Javascript, phishing re-directs are injected. Of course if the page itself has ad networks those are there by design.
Real story btw. I'm paying a bit of money for the host (not much though), I don't believe in ads taking money from the few reads I do get. Its basically a static page that costs pennies. I'm no longer updating the webpage, but I'm leaving it up just in case someone out there wants to learn more about the game. (It doesn't seem like any of the information is out-of-date. Its a few years old but the game hasn't changed in this aspect, so the information is still solid).
I just don't see any point converting this webpage into HTTPS.
Yes, I'm aware of MITM attacks and I'm also aware that fake certificates can be used to MITM even HTTPS sessions.
So I'm not convinced that HTTPS is the solution for that hypothetical attack. Not while untrustworthy certificate authorities are default-enabled on most clients anyway. At best, HTTPS complicates the attack but it doesn't make you immune to it.
A hypothetical MITM attacker can just get a fake certificate from a low-security vendor (ex: Comodo), and serve that to get a nice "trusted" version of the fake webpage. If you control the network, you control the certs that are eventually served to the users.
> At best, HTTPS complicates the attack but it doesn't make you immune to it.
That's literally all security. It isn't binary. It never is. At best, ASLR complicates ROP. At best, salts complicate breaking password hashes. At best, memory safe languages complicate buffer overflow attacks.
One could use your argument to dismiss basically all security. You've chosen zero mitm protection rather than a lot of mitm protection.
If you aren't using https then a network attacker with no preplanning can cause problems. If you are using https then a network attacker needs to get a bogus cert ahead of time. This costs money and time and does not scale well. Security is an economics issue. Making it more expensive to attack people is good.
Okay, I get what you're saying then. Your example isn't exactly the best example... but I "get" what you're trying to say at least.
You're saying that someone can inject a "redirect header" into a fake webpage, force that upon my users through the control of a network (WiFi router or whatnot), and use my domain name and my trust to take advantage of the users.
(Your example with the Zeus malware is bad because Zeus attacked the OS directly, so it wasn't a network attack. But hypothetically, lets say it was a network attack so that it remains applicable to my example)
Alas, HTTPS does NOT solve that, at least not while globally trusted HTTPS certificate roots remain insecure. They only need to get one HTTPS certificate signed by Comodo (or some other low-security HTTPS vendor) to attack my domain name in a manner like that.
That scam is mostly used through ad network vector not MITM. Btw it only references Zeus, it's not Zeus. A more subtle example is cryptocurrency miner scripts that result in your static page pegging a CPU core.
HTTPS raises the bar. There's no happily ever after in security. Maybe in five years domain hijacking and cert abuse will be as common as aforementioned fake tech support scams that prevent users from closing the tab. Some of them even set full-screen on desktop browsers and vibrate your phone (grr).
> That scam is mostly used through ad network vector not MITM.
Just one more reason why I'm not going to use ads to fund any web-projects I do.
-------
I agree that HTTPS raises the bar and makes it more difficult for certain scams. Indeed, I'd go as far as to say that any webpage with user-inputtable data (ie: username, passwords, etc. etc.) is required to be HTTPS. The risks are too great and that's the minimum security users expect these days.
But I'm still of the opinion that Web 1.0 style static-sites can be served with HTTP just fine. If there's no usernames, no interativity, and PURELY hosting static content in a community that's relatively lax (again: Minecraft and Eve Online fail. I'd use HTTPS even for a static site if I were doing Minecraft or Eve Online stuff), then I'd think HTTP is just fine.
> Christ you are ignorant about this kind of stuff.
Dude, I'm TRYING to have a discussion here. And frankly, I'm not fully convinced about the arguments that a lot of people are making here. Lobbing personal attacks is not cool, no matter the subject matter.
-----------
So hypothetically, you're saying a man-in-the-middle attack is going to change the content of my files. I understand.
Now tell me: how does HTTPS secure against that if Comodo certificates (or other poor-security certificate authorities) continue to exist?
A SINGLE bad certificate authority trusted by any of the major vendors would allow the attack you so described happen over HTTPS.
I have seen these things happen. HTTPS is not a magic cure-all, not while globally trusted bad CAs exist. Bad actors can still MITM HTTPS sites with a fake cert.
ISPs typically have some degree of HTTP proxying and caching available btw. You don't benefit from HTTP proxies / caches if you encrypt everything. So there's a reason. And if the bad actors can attack HTTPS with a MITM attack anyway, there's not much to gain from HTTPS from my viewpoint.
If a user goes to http://site.com, even if you have a redirector to the https://site.com version, the https version can be MITM'd with a self-signed certificate.
> If a user goes to http://site.com, even if you have a redirector to the https://site.com version, the https version can be MITM'd with a self-signed certificate.
At which point their browser will give them a big scary security warning.
