Hacker News new | ask | show | jobs
by CiPHPerCoder 2881 days ago
> I hate that I have to just because all you mofo's have forced me.

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.

2 comments

Okay, I'll bite.

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.

You're asking the wrong question, like many others who are resistant to HTTPS everywhere. HTTPS isn't for you, the site owner (although you gain the not insignificant benefit of knowing your content and traffic is untampered with). It's for the people that visit your site, so when you say HTTPS is a waste of effort and resources what you're inadvartently saying is that you don't give a fuck about your visitors - or at least, not enough of one to do the least you can to protect them from people who want to track and/or tamper with their browsing activity[1]. Especially since solutions like Let's Encrypt with certbot are free and take a couple of commands to set up.

[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?

If the user is so paranoid about this sort of stuff, then they can go get a VPS and control a large chunk of the network for themselves.

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 the user is so paranoid about this sort of stuff, then they can go get a VPS and control a large chunk of the network for themselves.

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.)

If I had usernames / passwords, then I'd use TLS.

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.

>But some webpages are simple, static

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.

>Nothing to steal, nothing to phish, nothing. Pure text, maybe a few images and videos to elaborate on specific points.

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

> I understand that TLS is important for any website with interactivity for privacy reasons.

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.

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.
Phishing for what though?

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.

I'd really recommend watching the video in this blog post: https://www.troyhunt.com/heres-why-your-static-website-needs...
Did you intentionally ignore the malware injection point?
Credit card numbers, Social Security numbers, online banking credentials, etc. The usual target data in fake tech support phishing scam.

example screenshot: https://www.pcrisk.com/images/stories/screenshots201703/zeus...

ISPs and other network operators are notorious for injecting content into webpages [0]. Even if someone is doing this for "harmless" or even "benevolent" reasons, someone else is cryptocurrency mining, tracking, nefariously manipulating content, etc.

[0]: https://thenextweb.com/insights/2017/12/11/comcast-continues...

Because otherwise an ISP might insert ads, or some adversary changes the content and inserts malware. Also, as a consumer of your blog I want privacy, no need for ISP to know what I click on and read exactly. These are just a few reasons why.
> Also, as a consumer of your blog I want privacy, no need for ISP to know what I click on and read exactly.

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.

If the site is using Cloudflare (free), AWS CloudFront (cheap), or another CDN, it won't have a unique IP address. For now, the domain name will still leak in plaintext through DNS and over the TLS connection in the SNI field, but browsers are planning to implement DNS over HTTPS [1], and encrypted SNI is on the way [2].

[1] https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...

[2] https://news.ycombinator.com/item?id=17401509

There's really not a need to. Others have pointed out that your ISP might inject ads, or something similar, another thing is encrypting only the traffic you want to keep secret leaks information about the fact that you're doing something you want to keep secret.

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.

Your argument, out of everyone else's, is the most sane. So lemme point this out:

> 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.

Okay, I am going to make free hotspot that serves your site as default starting page but with javascript malware downloader.

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?

But you could do that under HTTPS, with a self-signed certificate and have it load under HTTPS anyway. Or a variety of methods to get an illegitimate certificate trusted to some subset of users.
But I can't do that in the moment. Without HTTPS I sit on the network and see a clear request to your website. I intercept it and cause problems. With HTTPS I need to have planned ahead of time to target your website specifically and spent time and money on getting a bogus cert for your website. If your website is small I am not likely to do that. But I don't care how big your website is once I'm seeing cleartext traffic.
Hmm, well, in this case its as easy as running a script and clicking a button from this particular host. So I guess there's no major reason why not to do it (and it seems like my provider is defaulting to TLS from Lets Encrypt on any new sites made anyway). So its the new default way of doing things.

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.

All 3 of the concerns GP listed are completely agnostic to the topic of the web page or the behavior of its audience. It's not your fellow webpage visitors or community that are most likely to be in a position in the network to be doing MITM attacks.
> "I think the wins here far outweigh the temporary inconvenience of having to install/use certbot."

Installing certbot isn't something you can do on 100% of hosts. Switching hosts is also a pain.

I challenge you to find a host you can't install this on: https://github.com/kristapsdz/acme-client-portable

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.

"Heroku automatically manages TLS certificates for apps with Hobby and Professional dynos". It doesn't support free dynos.
You get to choose your own adventure here.

> 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.

> _

Then as I said: shame on Heroku.
So the solution is to run code that I have no idea if it will function properly on my host to see if it will work? But this is all supposed to be super easy, right? I was just supposed to be able to run certbot, and now I just need to run this random package that I hadn't heard of until 5 minutes ago.

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?