This is mostly accurate, to clarify the association IDs tie into what VLANs will be assigned and that does block all of the injection/MITM attacks. This also assumes that the VLAN segments are truly isolated from one another, as in they do not route traffic between each other by default including for broadcast and multicast traffic.
replyHowever client isolation should be a tool people have at their disposal. Consider the need for people to buy cloud IOT devices and throw them on a guest network (https://arstechnica.com/security/2024/09/massive-china-state...). It's also about keeping web-browsers away from these devices during regular use, because there are paths for malicious web pages to break into IOT devices.
What exactly a VLAN is (or rather, properly: broadcast domain) gets kinda fuzzy in enterprise controller based wifi setups… and client isolation isn't really different from what some switches sell as "Private VLAN" (but terminology is extremely ambiguous and overloaded in this area, that term can mean entirely different things across vendors or even products lines).
replyWhat exact security guarantees you get really depends on the sum total of the setup, especially if the wireless controller isn't also the IP router, or you do local exit (as opposed to haul-all-to-controller).
Yep, unfortunately fuzzy. For enterprise wifi deployments, one amusing thing to do when configuring 802.1X is to test ARP spoofing the upstream radius server after associating, and self-authenticate.
replyIt might be interesting to go and apply some of the sneaky packet injection mechanisms in this paper actually to try to bypass ARP spoofing defenses.
What can you even do on the local network these days? Most everything is encrypted before it leaves the device. I guess you could cast stuff to the TV.
replyProbably more of a problem if combined with other exploitable issues in other devices. Like if your TV doesn't properly check signatures on its firmware upgrades…
reply