I can't empathize with this perspective.
"Encrypt every packet with strong cryptography" is the mission statement of the information security community ever since Edward Snowden went public.
The "mofos" have "forced" you to protect your users from attacks like QUANTUMINSERT.
The "mofos" have "forced" you to protect your users from abusive ISPs injecting advertisements that track them into web pages that gain no revenue from these ads.
The "mofos" have "forced" you to protect your users from being hit with increased malvertising and watering hole attacks because ISPs generally cannot secure their own systems.
I think the wins here far outweigh the temporary inconvenience of having to install/use certbot.
Why would strong-encryption be necessary for a video game guide web-page? Say, one about Factorio?
Some game communities are toxic. IE: Minecraft guides I'd host with https due to the threat of scumbags and hackers. But Factorio's community is incredibly lax and laid-back. So I would consider HTTPS to be a waste of effort and resources.
In this hypothetical example, you're clicking on a video game guide. Someone watching you buy games from Gamestop would have more information than someone watching you click on "How Factorio Trains Work" or something else on this hypothetical example.
If the reverse DNS points to the IP address of the blog (ie: people see that you're browsing "FactorioGuide.com"), they're gonna figure out that you're learning how to play the game Factorio in any case. Even if all the traffic were encrypted.
The only way people don't know what you're doing is if the guide were on a shared host with many-many webpages on a singular IP Address. But otherwise, the typical website (ie: self-hosted on a VPS) would have a unique IP Address and a unique reverse-DNS entry. And people would figure out how long you've been browsing and what you've been looking at, even through HTTPS.
[1] https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...
[0]: https://thenextweb.com/insights/2017/12/11/comcast-continues...
[1] Unencrypted, pretty much everything about your internet traffic is laid bare for any middleman - your ISP, the person who controls the router you're connected to, some script kiddie on the same network as you - to both read and write. Injecting ads or cryptominers, tracking what pages you visit, changing what a page says, even straight up serving a different page. Why let your site/server be a (potential) vehicle for exploitation, disinformation and privacy invasion?
For everyone else, its a game guide. The worst that can happen is that they get the wrong information about how Trains work in Factorio. There wouldn't be a need for me to track users or clicks or whatever in a hypothetical game guide community website.
As I stated before: I know some game communities (ie: Minecraft or Eve Online) can be toxic. But the Factorio community isn't like that. So I'd be comfortable hosting a Factorio webpage under HTTP.
If I were hosting a Minecraft or Eve webpage however (warning: toxic community ahead), then I'd host it under HTTPS due to the dastards who troll and harass others in that community.
----------
That's the more important part btw: understanding your audience. Some game communities are toxic and full of harassers, trolls and so forth. But other communities are lax, friendly, and can get away with lesser amounts of security.
If it were a big network, like GameFAQs, Reddit, or you know, something where you can steal a password or something. Maybe you'd have a point.
But random blog with a bit of information on the game??
http://factorioguide.nfshost.com/
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.
There's literally nothing to phish here.
example screenshot: https://www.pcrisk.com/images/stories/screenshots201703/zeus...
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.
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.
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.
https://news.netcraft.com/archives/2014/02/12/fake-ssl-certi...
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.
And the last mile is still going to be just as unencrypted, non-private, and tamperable as before.
You literally cannot get end-to-end encryption/privacy without the host supporting TLS.
It's really not an optional thing to support for you as an operator, and especially now that Let's Encrypt is a thing, there's really no excuse for not doing it.
(Now that we're on the subject of toxicity anyway: I'd say that depriving your users from the ability to secure their network traffic, just because you're trying to die on a weird hill, is pretty toxic behaviour.)
But some webpages are simple, static one-off projects that I put out on behalf of a community. I don't believe in ads and would rather pay for all the bandwidth that my users would use. Consider it a donation "for the love of the game".
Very, very simple, nearly static webpages, close to "neocities" level of web design. No users, no passwords, just information I'm publishing to help a game community out.
Nothing to steal, nothing to phish, nothing. Pure text, maybe a few images and videos to elaborate on specific points.
http://factorioguide.nfshost.com
----------
I understand that TLS is important for any website with interactivity for privacy reasons. But the above webpage is completely static and non-interactive. Its old-school Web 1.0 stuff. There's nothing to steal, phish, or cheat here. Literally nothing.
I just don't see the point in HTTPS-ing this site.
Then you understand wrong. It's important for any website, interactive or not, for privacy reasons. Reader privacy is a thing regardless of whether something is interactive. I don't know where you're getting the idea from that 'static' sites are somehow special.
For example, Eve Online would 100% be under HTTPS. Period. That online community is incredibly secretive, incredibly untrustworthy, full of scammers and requires every bit of security on EVERY webpage.
Factorio's community? Erm... no. Trolls just don't exist in that community. Unlike Eve Online, there's no warring factions of spies trying to take over each other's online turfs "outside of the game". Factorio is a lax community without any trolls or hackers.
A lot of it is understanding the userbase and general security posture. If I were a serious Eve Online player, I'd give 100% secure settings, as much as possible, due to the shennanigans that community is known for pulling.
> Factorio's community? Erm... no. Trolls just don't exist in that community.
HTTPS isn't about protecting "secretive" shitty people. It's about protecting everyone.
But ultimately, I don't think that this vague concept of "privacy" when applied to a game guide really matters. People normally don't shuffle books and anonymize themselves as they put books back onto the library cart for example.
And I'm old enough to remember physical library cards with the names of everyone who checked out a book. I don't recall any privacy concerns about that. But maybe I'm just old-skool or something.
-------------
With regards to malicious ISPs MITMing their users: they kinda control your DNS requests, so good luck with that. I'm not sure if there really is a way to fully secure against an ISP-level attack against the users.
An ISP can always inject into the HTTP -> HTTPS redirection, and serve HTTP right there and then. HSTS assumes that the user has visited a clean version of your site before, if a new user comes in without ever seeing the HSTS, then the ISP still "wins" and captures your users on a fake HTTP version of your site.
So no, the level of attacks you've described, I don't believe HTTPS solves the problem.
HTTPS security doesn't depend on DNS.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ex...
Please keep in mind: I do app security for a living.
> An ISP can always inject into the HTTP -> HTTPS redirection, and serve HTTP right there and then.
...they said, in a thread about a popular browser marking HTTP insecure.
Do you really think HTTPS-by-default is out of the question in the future, especially if adoption rates exceed 99%?
I'm not sure why you aren't listening to other people. TANSTAASWS.
There ain't no such thing as a static website.... When someone can MITM you, the simple page you serve them can have all your content, with a complete redesign... Scripts, login places, anything the hacker chooses to put on it.
When you don't use HTTPS any middle man can take your content and do anything they want with it.
So I was reading this site and am particularly concerned about the crypto miner present on the page. Care to explain this to me? Hint: MITM due to insecure context and the miner isn't coming from the site itself but as a user, I'm going to blame the site because it happens on the insecure site.
If you think a MITM can't do any harm with a static page then you simply aren't being creative enough.
[0] Reusing a previous post of mine: https://news.ycombinator.com/item?id=17509373
These are not issues that are likely cause great damage, so no, there is no need to encrypt every last bit of traffic. But the bigger question is "Why wouldn't you encrypt it"? There's really not a lot of reasons not to.
> But the bigger question is "Why wouldn't you encrypt it"?
You're right. There's not a lot of good reasons I can think of. The best argument I've been able to come up with is ISP-level caching of HTTP traffic, which may save on bandwidth. But my host doesn't even charge for the measly amounts of bandwidth I use, so that's certainly not a concern.
Modern servers have HTTPS hardware-acceleration in the form of AES-NI, so it doesn't even use much more CPU power to use TLS these days.
So really, bandwidth savings from ISP-level caching is the best counter-argument I've got. Which is to say: not a very big concern of mine.
All people will assume that your page is installing malware on their hardware. Non tech people will not understand that was this free hotspot.
Now move a bit further, someone at ISP or network somewhere in world injects malware only into traffic of your page. I visited your page I got malware installed or my AV started alarms. Would they know that was not your site serving malware?
I'm not entirely convinced that it solves the MITM attack still. But I'm still not convinced that the arguments a lot of people are making around here necessarily make sense either. A lot of these attacks are fundamentally theoretical and don't seem broadly applicable.
The main argument that convinced me is: its easy to do, so why not? But the scare tactics that a lot of people in this discussion are unsavory to me and are unintelligent IMO.
Installing certbot isn't something you can do on 100% of hosts. Switching hosts is also a pain.
If you bring up that you don't control the host (shared hosting), then we should shame the shared hosting provider, who has no excuse.
> Ask Heroku to support LetsEncrypt on all dynos.
> Vote with your wallets and move away from Heroku.
> Launch a competitor that allows others to move away from Heroku.
> _
It's almost like this isn't a super simple process for everyone.
> "Conditional support for OpenBSD's sandbox, Mac OS X, or experimentally on Linux."
What now? I get to experience experimental functionality?
Remember that https offers both privacy and integrity, so even if you don't care about the privacy, you should care about the integrity.
I mean, there's the option to not use my site. Can I take a stand against HTTPS because I believe PKI to be a dumpster fire?
In any case, HTTPS doesn't protect your site, it protects the users of your site (by protecting the confidentiality and integrity of the data in transit). If you don't care about your users, then those potential users should avoid your site.
MITM attacks have become pervasive. HTTPS was less important years ago, but that time has passed. For example, ISPs, hotels, airlines, and many others have decided that it's okay to attack their customers. Supporting HTTPS is an easy way to help those users. It doesn't need to be perfect to be useful.
But the heavily flawed PKI is rapidly improving from the dumpster fire it has been. The glaring 'blindly trust every CA to never go rogue' problem is on the edge of being solved, with browsers beginning to require CAs to submit all new certificates to Certificate Transparency logs in order to be accepted. Attackers would have to either compromise multiple targets in detectable ways, or publicly disclose their forged certificate to the world before they can use it, at least once the older certificates from the dark ages of 2017 have all expired in a few years.