Hacker News Reader

Comment by lowwave | Hacker News Reader

Hmmm, why doesn't the site have https?

I think the author had a spat on twitter a while back because of the same question. There really isn't any excuse to not have TLS on your site, even if purely to thwart MITM injection.

Most arguments are BS but still keep popping up:

- heavy on the CPU (not with anything after 2006)

- hard to setup (not with LE + ACME)

- I don't process information (that doesn't matter/is not the reason, DPI, MITM come to mind)

- browsers can't handle it (lies, browsers handle it fine, unless you're using a browser from <2010)

Better yet: even if the resource/browser stuff were relevant, you can still leave http up and add https as an option.

> unless you're using a browser from <2010

To be fair, a lot of Jason Scott's audience is people who might choose to use ancient browsers on obsolete platforms.

Doesn't that make it double-bad?

Again, people might come up with the argument that it's their own problem if they get abused, but also that is just not the reality we live in; any compromised system can (and will most of the time) be used to infect/compromise/attack other systems.

Good luck trying to a attack an HTML only browser under a Z80 machine, for example.

Well, getting an RCE on that wouldn't be that hard I imagine. Not a whole lot of protections in there, and if there is an OS between the browser and the metal you can exploit that too.

And if you don't want to exploit the browser or the hardware, you can still simply inject a self-refreshing iframe in to the plain text html stream and have that z80 act like a (slow) proxy so you can do things that will point to that Z80 being the 'origin'.

Everybody assumes that 'simpler' or 'reduced' systems are always safer, but as soon as you deal with external interfaces and the outside world, that goes out the window. Lynx was thought to have less of an attack surface because it just did basic text-based browsing with HTML and not much else. Turns out that wasn't the case either.

links in Unix for example has automatic refreshing as a checkbox.

Well, then you use progressive rendering, or you use chunks, or you use something else. Sure, there might be specific mitigations that someone might have or have not set up, but that is not the point. The point is that assuming your system is safe is a bad position, and ignoring easy to use systems and processes to thwart complete classes of abuse is bad when you use a shared medium like the internet.

>I think the author had a spat on twitter a while back because of the same question.

Ok, I guess that explains downvote to my post. I was just wondering. Cause now we can get free SSL with let's encrypt. And since traffic and be hijacked and modified, it just seems to make sense to have a site that serves text files to have ssl.

Not every browser supports current https

This is the late 90s and https still takes too much CPU to justify for most purposes.

Because there are still plenty of valid use cases for HTTP.

No there aren't. All HTTP traffic can be modified, which means it can deliver any malicious payload to the server or client. It's dangerous not to use HTTPS, period.

This is silly, as the endpoint you're connecting to could also be malicious. If you're worried about trusting your intermediary, you can just VPN to a trusted host and use it as a proxy.

Or you can SSH to the server and read it from http://localhost (if you have access). But there can still be malicious software running, intercepting syscalls or your localhost domain can point to a malicious IP. :/ Software can't be trusted. Period.

https://news.ycombinator.com/item?id=22997403

this comment mentions their provider inserts ads in non-https traffic.

Reply on news.ycombinator.com