Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

ndss-symposium.org

Post reply on HN
Print view View original

21–30 of 204 posts

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#21

Post by andrewstuart2 »

cs702 wrote: post #6

Original source (should replace the current link): https://www.ndss-symposium.org/wp-content/uploads/2026-f1282... Summary: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif... (hat tip: https://news.ycombinator.com/item?id=47167975 )

Yeah, this is a much clearer source and the abstract gets pretty directly to the point. The first paragraph tells you pretty much everything you need to know before you read more. The Ars article took 4 paragraphs to mention "client isolation" and even longer to get into the meat.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#22

Post by ProllyInfamous »

runjake wrote: post #7
madjam002 wrote: post #5

Does anyone know of any good firewalls for macOS? The built in firewall is practically unusable, and if client isolation can be bypassed, the local firewall is more important than ever. I often have a dev server running bound to 0.0.0.0 as it makes debugging easy at home on the LAN, but then if I connect to a public WiFi I want to know that I am secure and the ports are closed. "Block all incoming connections" on mac…

Little Snitch is probably the most popular one, written my devs who deeply understand macOS firewall architecture. https://obdev.at/products/littlesnitch/index.html

Little Snitch is a user-friendly, software-level blocker, only – use with caution.

Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).

I liken the comparison to disk RAIDs: a RAID is not a true backup; LittleSnitch is not a true firewall.

You need isolated hardware for true inbound/outbound protection.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#23

Post by athrowaway3z »

iamnothere wrote: post #12
sippeangelo wrote: post #9

Bit of a sensational title? This doesn't "break WiFi encryption", only device isolation if the attacker is already in the same network.

Many businesses and universities, and likely some government offices, rely on client isolation for segmenting their networks. It’s a big deal.

Meh. The computers that:

- must not be accessible because their services don't use authentication/encryption

- and share a wifi with potential attackers

is just not that large.

They exist, but the vast majority runs in places that don't care about security all that much.

This should be a signal to fix the two things I mention, not to improve their wifi/firewall security.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#24

Post by strongpigeon »

benlivengood wrote: post #13

As far as I can tell, all of these attacks require the attacker to already be associated to a victim's network. Most of these attacks seem similar to ones expected on shared wifi (airports, cafes) that have been known about for a while. The novel attacks seem to exploit weaknesses in particular router implementations that didn't actually segregate traffic between guest and normal networks. I'm curious if I missed som…

That's my read as well. It's bad for places that rely on client isolation, but not really for the general case. I feel like this also overstates the "stealing authentication cookies": most people's cookies will be protected by TLS rather than physical layer protection.

Still an interesting attack though.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#25

Post by bookofjoe »

John23832 wrote: post #3
bell-cot wrote: post #2

On the one hand, a seems-solid article by an author I mostly trust. OTOH... with the recent journalistic scandal at Ars Technica, perhaps Dan should have made sure that he spelled "Ubiquity" correctly? (5th para; it's correct further down.)

That's an easy autocorrect issue. As someone who write Ubiquiti more often than most. I don't even think most editors would know the difference. That's the problem with using corruptions of real words as your name.

I once suggested HN implement auto-correct because there are so many misspellings here. I was quickly downvoted.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#26

Post by this-is-why »

Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to see how this is a risk to HTTPS traffic? It’s a mitm sure but it is watching encrypted traffic.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#28

Post by strongpigeon »

stebalien wrote: post #15

The article is hot garbage, here's the abstract from the paper ( https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif... ): To prevent malicious Wi-Fi clients from attacking other clients on the same network, vendors have introduced client isolation, a combination of mechanisms that block direct communication between clients. However, client isolation is not a standardized feature, making its security guarant…

A tad sensationalist perhaps, but "hot garbage" is a bit much.

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#29

Post by tialaramex »

benlivengood wrote: post #13

As far as I can tell, all of these attacks require the attacker to already be associated to a victim's network. Most of these attacks seem similar to ones expected on shared wifi (airports, cafes) that have been known about for a while. The novel attacks seem to exploit weaknesses in particular router implementations that didn't actually segregate traffic between guest and normal networks. I'm curious if I missed som…

The attacker doesn't need to be connected to the victim's network, only to the same hardware, the hardware's loss of isolation is the unexpected problem.

Their University example is pertinent. The victim is an Eduroam user, and the attacker never has any Eduroam credentials, but the same WiFi hardware is serving both eduroam and the local guest provision which will be pretty bare bones, so the attacker uses the means described to start getting packets meant for that Eduroam user.

If you only have a single appropriately authenticated WiFi network then the loss of isolation doesn't matter, in the same way that a Sandbox escape in your web browser doesn't matter if you only visit a single trusted web site...

Re: AirSnitch: Demystifying and breaking client isolation in Wi-Fi networks [pdf]

#30

Post by jeffbee »

iamnothere wrote: post #12
sippeangelo wrote: post #9

Bit of a sensational title? This doesn't "break WiFi encryption", only device isolation if the attacker is already in the same network.

Many businesses and universities, and likely some government offices, rely on client isolation for segmenting their networks. It’s a big deal.

Anyone who relies on client isolation was just waiting to get pwned anyway.
Post reply on HN