Hacker News Reader

Comment by oneplane | Hacker News Reader

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world).

https://www.troyhunt.com/heres-why-your-static-website-needs...

If your problem is some ancient device that cannot speak reasonably recent protocols, the solution is to not allow that device on the main internet directly. That might mean the device itself has to live behind a proxy, or it has to use a remote browser, or it might (as you might guess) simply be a matter of decommissioning the device or only using it on a local network.

Any time the general security of a system is downgraded for some edge case, that same downgrade can be used to attack everyone else.

View on HN

It's generally not a model that has much supportive mindshare for the web currently, but it is possible to achieve tamper-prevention without requiring the content of communications to be encrypted.

For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval.

That's reliable thanks to public-key encryption; the packages are signed, and the receiver verifies the signature.

Someone able to inspect your network traffic could, for example, tell that you've downloaded a genuine copy of "cowsay". Or they could detect that the server replied with a tampered copy (something that your client should reject as invalid).

[1] - https://wiki.debian.org/SourcesList#Example_sources.list

[2] - https://ubuntu.com/server/docs/package-management

Adding to that: just slapping HTTPS on those connections still would prevent an observer from detecting you downloading cowsay. IIRC every package has a fairly unique size and unless you add padding that is enough metadata to figure out with reasonable certainty which package you requested. So it’s not like HTTPS would add any immediate benefit anyway.

Systems that are older than general SSL and TLS usage do indeed have those features, but they are mostly unsuitable for the majority of internet users.

Sadly, it could have been better with varying options of choices in connection, stream and content encryption methods, but that simply isn't feasible with the users and scale we're currently working with.

For niches (and operating systems and software packages are niches, even if an end user is somewhere under the hood using it) it can still be pretty good, especially considering the mirror system where you distribute files to mirrors which might themselves use TLS but you'd still want the distribution authority to be the only one signing those files.

> For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval.

But then you've bootstrapped the trust somehow. If you were to download an ISO from that not-HTTPS website, you'd be at risk.

Visiting a single unencrypted website allows anyone who controls the connection (your government/ISP/WiFi provider) to cause your browser to silently execute malicious code and download malicious content. Compromising the security of 99.9% of users for the benefit of the 0.1% isn't even remotely worth it. Those 0.1% also have a simple workaround of using a proxy if needed.

Seems like a browser issue, not a website issue.

Browser's can't verify the integrity of website contents.

HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.

TLS protects completely against network based MitM attacks.

CDNs are purposefully installed in MitM positions. That's a risk that the sites owner has to manage and it's an optional one at that.

A well funded actor would probably use different kind of vectors and not even bother with website MitM.

So why does catmemes.lol need to be encrypted with such urgency?

Because random ISPs will inject ads in websites for example.

That seems like a poor choice of ISP to me. If I dial my phone and have to listen to ad jingles before it connects, I'm changing my phone company.

That type of response comes from a place of privilege. Many have no choice over ISP.

Dysfunctional markets is a legal problem, not a technical one. Concealing the consequences of market dysfunction with technological band-aids only serves to preserve the status quo.

This is just a deeply unhelpful way to think.

Firstly it punishes those in the worst situations. Those in countries with abusive political systems, those who have no legal representation, etc.

I don't even believe the idea is right in practice "serves to preserve the status quo" is just wrong in this case. HTTPS completely breaks most terrible things ISPs can do. It completely dismantles the system.

> Firstly it punishes those in the worst situations. Those in countries with abusive political systems, those who have no legal representation, etc.

HTTPS offers virtually no defense against a state actor.

> I don't even believe the idea is right in practice "serves to preserve the status quo" is just wrong in this case. HTTPS completely breaks most terrible things ISPs can do. It completely dismantles the system.

HTTPS doesn't dismantle the system at all. You're still stuck with no other option for an ISP, which means you are not going to get favorable terms. And even with HTTPS, you need to look up the IP for the servers you're going to visit, and ISPs can snoop on your DNS traffic and sell information about how you, the IP (or the person), regularly looks up the IP for abortionpills.example.com (or connects to the IP associated with the server).

They get an IP but an IP does not always equal a hostname.

It's just one data point though. The real juice comes when you have a hundred thousand traffic logs to compare, then you can start inferring similarities even from vague and incomplete data points.

> Seems like a browser issue, not a website issue.

That's why Mozilla and Google have been working on the transition to HTTPS for years.

Mozilla announced deprecating HTTP back in Apr/2015 [1], to allow plenty of time for everyone to upgrade.

1. https://blog.mozilla.org/security/2015/04/30/deprecating-non...

Right, but if the security threat is the browser silently executing malicious code, shouldn't that be the fix, rather than the protocol? HTTP data itself isn't harmful.

JavaScript code can be malicious, even while sandboxed (e.g. downloading a file). There are still dozens of browser security issues found and fixed every month.

A simple HTTP redirect to download a PDF file can also lead compromising the user's computer.

How does HTTPS protect from any of that? PDFs can still compromise your computer, and JS is still sketchy. Anyone can encrypt their server, even the bad guys.

That only happens if you directly visit a malicious site, e.g. https://secure.mybaaankingsite.com

You can protect yourself by going directly to the URL and checking you're on the right domain.

If you don't enforce HTTPS everywhere, any website is potentially malicious, e.g. visiting http://cookierecipes.com can have the same consequences.

Right, but how do I know whether the URL pattern is legitimate? I don't work for the IT department at my bank. If the answer is to just eyeball it, that does seem like a far worse security problem than HTTP has ever been.

HTTPS isn't a panacea for all security issues. It ensures that when you connect to website.com, you'll get whatever website.com sends to you, without anyone else eavesdropping and tampering with the connection.

HTTPS doesn't prevent you from going to weebsite.com. There are other security measures for that, but it's also your responsibility to check.

It doesn't even do the first thing. There are multiple vectors where someone could tamper or eavesdrop on a HTTPS connection, perhaps the biggest one being CDNs. As a visitor, you have no real idea how secure the connection is, even if it has a "padlock". HTTPS offers some protection against local attack vectors, from your ISP or on a public WiFi, but that's about it. The server could be compromised, or malicious, you have no idea.

Putting the responsibility for checking the rest on the user is honestly a mistake. They could be dyslexic, and may not be able to detect a typo. They could also be 85 years old and not understand half of what you are saying. These are the problems browsers should be focusing on. Security is not as easy as encrypting the protocol and saying everything else is user error.

You keep sidestepping the benefits. You want website.com you get website.com. It's impossible to know the infrastructure of that website and simply isn't something HTTPS will fix. That's more of a social/legal problem of how companies can handle user data.

The benefits are pretty small compared to the cost of requiring HTTPS everywhere, which is allowing silicon valley to bully the entire internet into jumping through its hoops to get traffic.

The websites that aren't willing or able to do so are, in my experience, some of the more precious ones we have on the Internet. The websites that aren't trying to monetize their visitors are the ones that get Thanos:ed out of apparent existence. What gets lost isn't the spam or the malicious websites, they of course adapt. What gets lost is the unique views, the personal websites, like from some 80 year old who has meticulously published a catalogue of his astrolabe collection online over the last 30 years.

> to cause your browser to silently execute malicious code and download malicious content

You are making assumptions about my user agent.

If you use insecure JS-executing browsers and problematic ISPs (I know not everyone has a choice), consider VPN or an extension that forces HTTPS.

I thought the whole reason for encrypted connections is to deny information as much as possible from intermediaries (ISPs), so those who control servers can hoard all the information to their own benefit?

Initially, the main reasons were:

- Identification (bi-directional)

- Privacy (or secrecy)

A side-effect of those are tamper resistance. As the internet got older, more tamper-based abuse was happening and the benefit of tamper resistance became practically more important than the identification part. To be realistic: most people don't actually know how to identify what website they are on, and they also don't know what the identity should be. This is also why EV (extended validation) is completely worthless and mostly purged from webbrowsers.

some ISPs still to this day try to inject their ads when HTTP is used, especially on mobile. I was very angry when I noticed it first time with my mobile operator. No such luck with HTTPS.

Reply on news.ycombinator.com