Hacker News Reader

Comment by tokenizerrr | Hacker News Reader

That's not a security issue if the site doesn't ask for user input, though.

Since the other examples don't appear to have convinced you, how about this one: https://samy.pl/poisontap/

Visit a single HTTP page while that's plugged in and it'll trigger an exploit that siphons all non-secure-flagged cookies off of every popular site that doesn't use HSTS (including the config pages of insecure routers on your LAN), and installs a persistent backdoor in them so the attacker can continue accessing data on those sites even after you're no longer being MITM'd. And that's not even using any zero-days; it's just exploiting the inherent vulnerabilities in non-secure HTTP.

(Note that while the site I linked talks about a USB device the same attack can be carried out by any MITM, like a WiFi router or upstream ISP; it's not exclusive to local attackers.)

Interesting, and point well made. Thanks!

Wait. This is a DHCP exploit on steroids. The MITM stuff is just possible because operating systems accept bonkers DHCP replies.

Yeah, the DHCP trick is what allows this particular method of conducting MITM via USB.

All the stuff it does _after_ becoming a MITM though are things that any MITM could do, regardless of how they became a MITM in the first place. (ARP spoofing, operating or compromising a Wi-Fi access point, etc.)

An example from the real world -- Comcast, a large ISP in the USA, has been caught injecting JavaScript into websites: https://thenextweb.com/insights/2017/12/11/comcast-continues... It's not hard to imagine a more malicious use, like tracking or injecting adverts the ISP wants you to see on webpages.

This is only possible because the connection isn't encrypted.

Another example -- Verizon were injecting a header called X-UIDH which had a unique identifier, acting as a super-cookie that was present on all websites and couldn't be removed: https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

This is only possible because the connection isn't encrypted.

Every website needs SSL.

All of that is bad, none of it is a security issue. Privacy, sure. But not security. And the article specifically shows that Google is planning to mark example.org as insecure. Which it's not.

But it quite literally is:

    insecure (adj.)
    (of a thing) not firm or fixed; liable to give way or break.
    not sufficiently protected; easily broken into.

A webpage loaded over HTTP is easy to tamper with. Let me give you an example of traffic over HTTP that is secure -- apt repositories; because you're only retrieving payloads protected by PGP, so the actual payload is firm, fixed, and not easily broken into.

How else do you define insecure? Have I misunderstood the definition?

I define insecure as a machine/user getting compromised. Malware, phishing and the like.

Anyway, your example is a good one as to why it's weird for Chrome to label these things as insecure.

Insecure can't be used as a drop-in replacement for compromised though; Being insecure will get you compromised. One distinct thing might lead to another distinct thing

> I define insecure as a machine/user getting compromised

So a bank using plaintext HTTP doesn't qualify an insecure?

Integrity is one of the components of security.

Sure it is. If I have a Chrome exploit that I want to deliver to you and I'm on your network I can inject it into the webpage.

Yeah. You could also just host it literally anywhere and post an URL in the comments here. By that logic clicking on hyperlinks is equally insecure.

Your argument seems to be that because there are multiple ways to exploit people that closing any of those methods is not useful. I shouldn't have to explain why this is not a meaningful argument.

What I will say is that in many cases an attacker is far more capable of MITM than they are of posting forum comments, or otherwise convincing you to click a link. A phishing campaign is noisy - you are often alerting many parties that you're malicious. MITM within a network is much stealthier and you don't have to rely on users clicking on anything.

Really, they're just completely different attacks and the existence of one has no bearing on the other. TLS on every page would close off real attacks and, if it forced attackers to use noisy methods like phishing, that's a huge win.

Reply on news.ycombinator.com