Hacker News Reader

Comment by tonmoy | Hacker News Reader

If I were a hacker I could try to MITM this site that serves executables like games and applications and inject something nefarious. I don’t see not having HTTPS as a positive thing.

View on HN

TLS allows the browser to detect content (like scripts) injected into original web pages by (potentially) malicious third parties. Or at least by third parties who aren't using certificates issued by roots explicitly trusted by the browser software. Before the use of HTTPS in the early 90s, it was not an exceptional condition for third parties to insert content (ISPs inserted ads, libraries inserted cookies, BGP hackers just looked at traffic). One of the reasons SHTTP and HTTPS were invented was to allay fears by banks that entering credit card numbers on non secure links would increase the rare of fraud. But the main reason (I believe) we use HTTPS on sites that don't take CC#s today is because we cannot enumerate every potential risk. Because we cannot forsee the risk, doesn't mean it doesn't exist. In other words... "better safe than sorry."

MITM became some sort of miraculous hacker solution.

To MITM you need to be on the way of the traffic, or manipulate the DNS. None is obvious.

Just create an open wifi called „free wifi” in any crowded place…

Too obvious - just give it the same ESSID and password as your local coffee shop's network, and let the "Connect Automatically" setting on Windows do the rest.

Many if not most WiFi clients send a list of SSIDs they would want to connect in cleartext in their directed probe request frames in the active scanning mode. I expect there are attackers automatically advertising these networks to lure in devices.

This is far from being obvious to find out and hardly a scalable MITM.

These are always the same tricks that work in a lab, but then when it comes to do an actual MITM on a web site - there are no solutions.

If my web site is www.example.com, you would need to get very close to the site (network topologically speaking) and insert yourself in the traffic. This is in practice undoable, except if you hack the local network where the web server lives (specifically some equipment) or the server itself.

Or hack the DNS server.

None of these are remotely easy with basic security in place.

My remark was tongue-in-cheek. I'm aware that this would only go as far as appearing as a bridge router, which Windows often designates with a number after the name (e.g. WittyNetworkName 2). It's not very subtle, and you would likely only intercept a fraction of the traffic from a client, as they would default to directly contacting the host where possible.

Do you recall the days when it was common practice for ISPs to MITM all traffic?

The most obvious and profitable use case were those ISPs who returned 404 pages riddled with advertisements for domains that were unregistered (e.g. if you mistyped a URL)

Certain ISPs even injected JavaScript into every page.

“I” in the OP’s comment probably means “government” or “ISP” rather than a friendly roommate on the same wifi network.

> Do you recall the days when it was common practice for ISPs to MITM all traffic?

This never existed in France. That would have been completely illegal.

There was a time when this existed in France and was not illegal. I believe that's why the OP was saying "Do you recall the days when..."

When was it, and with which ISP?

Not op, but see this

https://www.usenix.org/legacy/event/foci11/tech/final_files/...

France isn’t listed, but Germany, Netherlands, United States (obviously) are. This was a thing that used to commonly happen before TLS became standard.

Bold of you to assume lawmakers would be ahead of hackers on the technology front.

And how could you do this, Mr. Hacker Man?

Are you compromising my ISP, the server host, or my client?

In any of these situations, I have a bigger problem than TLS, and a lot of vectors I can be attacked from.

HTTPS isn't always needed, and the idea that it is needs to die. Most use cases it does make sense to use HTTPS indeed, but there is a small number of use cases where it doesn't make sense.

You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise.

Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests.

But again, probably 99% of cases it's better to have HTTPS than not. But sometimes not having HTTPS is indeed a positive thing.

> You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise.

That's incredibly niche. I don't think it deserves to be an example of "meme needs to die".

> Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests.

Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification.

And thinking of "memes that need to die", https://istlsfastyet.com suggests this isn't as bad as I think you think it is.

> That's incredibly niche

The very website we're talking about in this submission is specifically made for vintage computers! But I agree, relatively niche.

> Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification.

That gets passed out-of-band before actually downloading anything from the registry. In the case of Arch, every package is signed by developer keys that are securely fetched on initial install, and later fetched as a package.

Less niche use cases are doing latency sensitive things over HTTP (which overall I wouldn't recommend, but sometimes you're stuck with 3rd party stuff), then adding the handshake can easily double the time for the connection.

For example, one website I have can have the TCP connection be established in ~40ms, while the SSL/TLS handshake takes ~100ms. So because of SSL/TLS, the request time more than doubled. If I was serving signed packages over this connection, you can easily skip the handshaking part and when you download thousands of packages, save some time. I don't think that use case is as niche as you think.

Reply on news.ycombinator.com