Hacker News Reader

Comment by diegorbaquero | Hacker News Reader

Excellent write up. That’s why we need SSL/TLS with HSTS. Pure HTTP, specially in public WiFi, is dead.

Since we won't get https everywhere soon, is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?

If you control the AP, you should disallow client to client communication. Most AP's and routers allow this and it would mitigate this risk.

Is there any way to mitigate this without limiting abilities of people on the network? It kind of destroys the point of a LAN.

don't take my word for it, but I'd bet you could disallow LAN comms on port 80 and prevent this. Typically a toxic client would flood the arp table until the router believed the toxic client should receive all communications and then the toxic client would mitm and forward traffic on the expected port to other normal clients...if the toxic client can't send stuff on port 80 to a normal client they can't easily mitm them

Yeah, but it would still redirect, since that's a different layer of the IP stack.

You could prevent wifi clients from communicating arp packets, I think that would allow most things to work.

If you have a corporate wifi system, you should be watching for arp poisoning anyway. If it's a public system, most people aren't using it to communicate between wifi devices. Most android devices that communicate via wifi will generate their own wifi network for the duration of the communication.

Did you ever use LAN functionalities in public Wifi (e.g. Starbucks)?

I did once at a hotel. Someone on the LAN kept what appeared to be his entire MP3 collection in his Shared folder. So I downloaded the whole thing.

Turned out he had crap taste in music and I ended up deleting my copy.

CoffeeMiner mixed with a WiFi Pineapple seems like the way to go.

Pineapple is overkill. You can use any open-wrt device or Linux laptop with a card supporting hostap.

Just give it the ssid 'xfinitywifi'.

But... this doesn't use client to client communication. As far as the AP is concerned there is one client (the attacked). The victim is connected to the attacked believing the attacker is the AP.

To the AP, they are both clients. The attacker (MITM) computer can be accessed by the victim. This would mitigate the attack. It's possible that the arp spoofing would prevent the victim from accessing the internet, but that depends on how the AP institutes it's blocks.

I think we will get it everywhere soon.

And no, that's not a solution. Well at least not everywhere. If the clients aren't completely isolated I can for example poison your DNS and redirect example.com to my computer's web server.

>is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?

AFAIK that wouldn't help because at the very least you can MITM the handshake.

Honestly any decent public wifi setup even if it isn't going to limit client to client communication, if that's needed for some reason, should be restricting based on protocol/port/etc. It should be a whitelist, not a blacklist. There's no reason a client should be able to touch HTTP traffic towards anything but the gateway.

This is trivial to set up with for example, even a cheap sonicwall.

> is WPA2 on a public Wifi with a publicly known key a workaround?

You're thinking of packet injection (or data intercept) by any nearby individual, which WPA2 with known PSK would mitigate. However, as an attacker would know the PSK, they could simply join the network to side-step this.

I've heard of, although never implemented, using WPA2 Enterprise authentication for public access points, and then just have your RADIUS server reply with a success regardless of username and password combination.

At first I thought this was a terrific idea, but never tried it since I figured having a non-standard workflow for users to connect may cause too much confusion in the end.

Reply on news.ycombinator.com