Hacker News Reader

> Even on static sites, HTTPS prevents a MITM from telling what pages you're reading, or introducing falsehoods into the content. It's not "overuse" to use HTTPS there.

Also scripts. Even if the site itself is completely uninteresting to an attacker, he can still inject scripts which attack 3rd-party sites or exploit browser vulnerabilites to gain access to the machine. (Though, to be fair, the same is possible with ads)

> If you care about sustainable technology, you should be demanding that Apple provide updates for hardware longer, or open-source everything so that the community can.

I can't really agree with that point. How much longer is "longer" supposed to be? 6 years? 10 years? 50 years? To a software dev, supporting any piece of technology for 50 years sounds completely outrageous, yet that was the generally accepted lifespan of many consumer devices not long ago.

IMO, hardware/software that requires continuous updates is not sustainable, period. At some point, you'll always be in a position where the vendor is unwilling to keep up work for a product. Maybe you'll have some volunteers to fill the gap, but that's nothing that you can take for granted. At that point, if the device becomes e-waste, it's not sustainable.

demanding apple do ANYTHING is sort of an uphill battle.

> How much longer is "longer" supposed to be?

For as long as nobody else is capable of doing so. Don't forget the part where I said "or open-source everything so that the community can". If they did that from day 1, I wouldn't care if they never provided any official updates.

More arguments to always use HTTPS:

https://https.cio.gov/everything/

https://developers.google.com/search/blog/2014/08/https-as-r...

The load time is contingent on ping, for instance with TLS over TCP you need 3 full round trips to get a pipe that can carry HTTP, this is 3x as many as with TCP alone. In the author's scenario there's a 500ms delay, so naively that's ping of 250ms which is really high. In the case of HTTP/1.1 or asset loads from other origins, there may be additional connections that are made which will all incur the extra overhead as well, though the author's blog is served over HTTP/2 which wouldn't incur this cost for same origin asset requests. For me best case for author's blog (just the HTML via curl) is 250ms plaintext and 600ms TLS. What's more interesting is that plaintext is a lot more consistent for me because I have pretty bad packet loss and the HTTP request fits into a single TCP segment.

I don't know why your browser cannot redirect to https and the web-server has to do it.

Your browser can redirect to HTTPS, if you use HSTS preloading.

Also, at this point I think we have sufficiently pervasive availability of HTTPS that it'd be reasonable for browsers to expand typed domains (if the user types `example.org`) to use https:// rather than http:// , unless they're an IP address or localhost.

HSTS preloading requires that you have the redirection on your site though, as per "Submission Requirements" on https://hstspreload.org/

Which is one of many good reasons why you should have that redirection enabled. Or disable HTTP entirely (the HSTS requirements say "if you are listening on port 80").

FWIW, it doesn't require (or at least check) that you redirect for your whole site, just / on the apex domain. I've got a larger post elsewhere in the thread with detailed recommendations for how to use HSTS for modern browsers and let old browsers do http.

Firefox does this (if you tell it to) and it's in the works for Chromium as well IIRC.

I believe the chrome address bar defaults to https now: https://blog.chromium.org/2021/03/a-safer-default-for-naviga...

> * Even on static sites, HTTPS prevents a MITM from telling what pages you're reading, or introducing falsehoods into the content. It's not "overuse" to use HTTPS there.

I hear this argument again and again. You need to understand it's completely useless for websites where you are a passive consumer (i.e. you don't enter any information, just read articles and so on). And, frankly speaking, MITM attacks on passive websites are much rarer than errors related to outdated (and sometimes misconfigured) certificates. Enabling HTTPS redirect means the fallback is no longer working, and if the browser doesn't let you in, you basically lost access to information even though it is still right there, just inaccessible.[0]

[0] Yes, website owners should configure their certificates properly, the process is now very easy, you can add certbot to crontab and forget - but it turns out in real life it doesn't work like this.

> You need to understand it's completely useless for websites where you are a passive consumer (i.e. you don't enter any information, just read articles and so on)

It's not. ISPs have injected ads. It also gives slightly less data to for ISPs to track since they only get the SNI header (domain name), not what articles you visited.

You could argue that ISPs shouldn't do that, and I'd agree, but unfortunately many people don't have a choice of ISP and some ISPs are shitty.

Yes, this is something I hear from my colleagues in the USA (I haven't seen it in Europe yet, it's unthinkable for me). Note that in this case you can perfectly use HTTPS. What we are talking is the situation where the website owner redirects HTTP to HTTPS (and in this case the ISP sees at least the initial article address anyway).

It is not "completely useless" or a "theoretical attack vector". This literally happens in the wild. There were reports of Comcast and ISPs in India MITM'ing traffic injecting ads into their their customers' tcp streams a couple of years ago.

> Enabling HTTPS redirect means the fallback is no longer working, and if the browser doesn't let you in, you basically lost access to information even though it is still right there, just inaccessible.

This is the equivalent of saying that "since phantom issues with preflight checks on airplanes can sometimes result in cascading delays of flights on an entire airport therefore we should get rid of preflight checks on commercial airliners".

> It is not "completely useless" or a "theoretical attack vector". This literally happens in the wild. There were reports of Comcast and ISPs in India MITM'ing traffic injecting ads into their their customers' tcp streams a couple of years ago.

In this case people can freely use the HTTPS version. What we argue is stop doing automatic redirects effectively rendering the whole content inaccessible in case of certificate issues - and this a massive problem, affecting much more websites than hijacking traffic by some ISP some years ago. And you can be sure ISPs will be doing less of it as most sites are on HTTPS now. What we are asking is not to kill plain old HTTP for those who want and need to use it.