Hacker News Reader

> Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.

Not just governments. I can get in my car and go to the three main shopping malls in my relatively large Portuguese city. I will very easily MITM a bunch of people there, no problem, using a variety of attacks. They won't realize that I'm now sucking all their traffic in and modifying it as I please.

After I've done that, if they visit any HTTP link, I can inject whatever I want there: crypto mining, download links to a modified/hacked version of their browser, social engineering attacks (phishing), cookie hijacking, etc. Notice how I can modify whatever HTTP page you have to link to websites you think are secure (banks, social media, websites), but that are modified (e.g. via sslstrip, or just by being similar-but-not-quite-the-same-hosts, etc)

Many months ago I went through this here: https://news.ycombinator.com/item?id=25123366

It should be a duty for all sysadmins to make sure their sites are HTTPS. Sure, if they're only in an intranet, HTTPS is likely overkill. But any publicly hosted website should be forced to be HTTPS.

One single HTTP website leaves a person vulnerable to millions of attacks. Many of these are still present on the web with HTTPS -- but at least then they'll typically be done by the people running the HTTPS site, not by someone in the middle.

It seems firesheep[0] is fading from the internet's institutional memory. Seeing it action was startling for most of us at the time.

[0] https://en.wikipedia.org/wiki/Firesheep

Security is about the ”CIA triad“, i.e. confidentiality, integrity, and availability.

For those sites you mention, confidentiality and availability will not really be impacted by HTTPS.

But the integrity can be.

Case in point: See this comment https://news.ycombinator.com/item?id=27507826

HTTPS is definitely useful for preserving the integrity of data between the server and the end user.

To be clear, I'm very pro-SSL and have used LetsEncrypt for years on all my domains. I was just taking issue with the notion that someone's web server serving static content could be breached just because it didn't have an SSL cert.

I mean define breached? I don't think anyone ever would say that without TLS you can use HTTP to drop into a shell on the server. But you can, largely arbitrarily, mess with the content of the site if you're adjacent to either the sever or client, or in the path between them. Maybe this matters a lot for someone's security, maybe it doesn't at all.

Breached as in someone else has control over the server.

If you can hijack the connection (i.e. MITM) you don’t need to control the server in order to compromise the integrity of the information.

True, but this would not satisfy "breached".

I had the same feeling as you recently, until I read a site posted here a few weeks ago. I can't find it now, but it was a personal page where someone described in increasing levels of severity what can be done over an unsecured HTTP connection even if there is no private data transmitted over it. Can someone help?

Because unencrypted HTTP allows attackers to MITM the traffic, they can do things like put ads on your site, inject malware or bitcoin miners, or just replace your site completely. None of those affect you, the site owner, directly, but ìt subverts the purpose of your site and lowers the value and trustworthiness of your site to your visitors.

Frankly, I feel it's very good, because at this point you notice your network has been hijacked and this is the first step to solve the problem. Patching it with HTTPS (especially without HSTS) won't solve the problem, it will just make it more difficult to discover by an unsuspecting user.

Most anyone who is in a position to reliably MITM an HTTP site would also be in a position to install a certificate source (either as part of a “install this to access the web” program or similar).

It’s a necessary level of defense but it is NOT sufficient- especially if you never check certificates.

Not really. In my experience it's always been an ISP that modified the HTTP in transit (to add their own advertising and analytics JavaScript inline), and the ISP didn't have the ability to install a certificate source.

I highly recommend you do a search for Firesheep - the tool that really started the push for HTTPS everywhere. You're right that a malicious network operator would be in a position to request users install root certs, but the problems with plaintext HTTP are deeper than just that.