If you were an early user of computer networks, you may remember early Ethernet networking, with its treacherously unreliable co-axial cabling and its unyielding wiring rules.
Very loosely speaking, Ethernet was derived from ALOHAnet, a wireless network invented at the University of Hawaii in the late 1960s and put into service in the early 1970s.
ALOHAnet was an excellent example of the saying that “necessity is the mother of invention.”
It was inspired, apparently, by its creators realizing that although long-distance wired communications in Hawaii were expensive because they depended on circuits leased from the US government’s then monopoly telephone provider, wireless communication via taxi radios was largely unregulated, and could travel surprisingly long distances, even between islands.
If taxi radios could be repurposed from transmitting bursts of human speech between drivers and dispatchers to transmitting bursts of digital data encoded as carefully controlled warbling sounds in short packets, perhaps the university could avoid leasing permanent data circuits from the phone company altogether?
The system worked, albeit at speeds under 10 kbit/sec, and inspired Ethernet, which followed similar principles but used a shared, shielded copper wire running between connected computers to achieve very much higher data rates.
Both these network types, wired and unwired, relied on broadcasting network traffic to everyone in a series of data packets, but tagging each packet in such a way that the intended recipients could figure out which packets to ignore.
Simply put, everyone gets everything, but the system works because the devices on the network can quickly identify and discard packets that aren’t for them, so they don’t waste time processing data that they don’t need.
Of course, this means that anyone within network range – anyone who can tap into the “antenna cable” in the wired case, or anyone within radio range in the wireless case – can deliberately accept all packets, and either store them up for later analysis, or process them in real time to look for interesting or important data such as passwords, authentication codes, and much more.
The process of capturing network packets that aren’t really meant for you is known in the jargon as sniffing, and although this can be a vital part of network troubleshooting and software debugging, it’s also the stuff of dreams for cybercriminals, spies, and other malcontents.
If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.
Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
Over the years, Ethernet networks shifted from a single “antenna cable” that had to snake its way past every computer on the network to a hub-and-spoke system in which each desk or computer was wired up individually, often to a rack in a purpose-built wiring closet, and then interconnected via digital devices known first as hubs, and later as switches.
Although this meant more wires and wiring, it greatly improved reliability, because a break in any individual computer’s connection to the network would no longer break the entire system.
That’s what would happen every time the “snake antenna” in a co-axially cabled network suffered a break or a bad connection.
Co-axial Ethernet was subject to strict rules about cable lengths, continuity, resistance, impedance, and more to ensure that the signal was always well-formed enough to work at its supported data rates.
Hubs simply received incoming packets on each port and regenerated them as outgoing packets on all their other ports, so that everyone still got to see everyone else’s traffic, and sniffing tools could still, for the most past, suck up everything on the network.
Switches, which quickly followed, had more processing power of their own, and kept an internal map of which computers were connected to which ports, so they could send each user only the packets they truly needed.
Switched networks effectively pre-filtered the outgoing data on each port, instead of relying on every network card on every computer to filter every packet. (Switches often have special uplink ports, for hooking up to other switches, with higher communications speeds than ports that filter traffic for individual computers only.)
The primary motivation for moving from hubs to switches was efficiency and speed, but the side-effect was to make network sniffing harder, because only other switches, or computers plugged into special sniffing-enabled ports on the switch, could track all packets to and from everyone.
This wasn’t security-by-design, but it nevertheless made sniffing a lower-priority security concern, not least because it prevented malware from trivially snooping on the whole network just by infecting any single computer on the network.
But history has a habit of repeating itself.
Although wired Ethernet originally replaced the wireless networking of ALOHAnet, wireless networks returned in force in the late 1990s and early 2000s, thanks to their convenience.
The introduction of a global standard known as Wi-Fi in 1999, coupled with the rapid increase in speed and reliability of Wi-Fi technology (from about 2Mbit/sec in the 1990s to more than 10Gbit/sec today), meant that the “almost accidental” security benefit of switches in wired networks vanished abruptly.
In early Wi-Fi networks, such as you might find in a coffee shop, not only the owner of the coffee shop (or an intruder who had broken into the wireless router) but also any device connected to the LAN could trivially sniff out and capture everyone’s traffic.
Anything unencrypted would, or at least could, end up as a matter of public record, with walls and windows providing little or no protection against eavesdropping from a distance.
Even encrypting the Wi-Fi traffic automatically between clients and the access point based on a Wi-Fi password didn’t really solve this problem.
Any user who already knew the network password, for example because they had previously visited the coffee shop and connected successfully, and who was listening in when another user set up a Wi-Fi connection, could recover the session decryption key for all the future packets sent and received by that user during that session.
Only if an eavesdropper arrived and connected after another user would that user’s traffic be properly shielded from snooping. (WPA3, which many routers now support, overcomes this particular issue, so you should use WPA3 if it’s available.)
In other words, although WPA and WPA2 encryption protects against short-term sniffing by attackers who simply drive past, it isn’t enough on its own to prevent snoops from retrieving data sent across the Wi-Fi network.
Opinions about the risk of Wi-Fi sniffing came to a head in 2010, when a free Firefox plugin called Firesheep was published to prove just how easy it was to hijack other people’s online accounts if the service they were using didn’t use HTTPS end-to-end encryption properly.
HTTPS was considered slow and expensive back then, because it adds some computational and network-level overhead both to setting up connections and to exchanging data.
Many major sites, including social media and webmail services, therefore used HTTPS only when you logged in, which protected your username, password, and 2FA code if you had one, but then sneakily switched back to insecure HTTP for all the messages you sent and received thereafter.
By doing this, they gave their users the impression of taking security seriously, while self-servingly saving themselves the overhead of using HTTPS all the time.
Of course, this meant that the authentication cookies used in subsequent network packets to authorize your session, and to keep you logged in, traveled over HTTP and not HTTPS, so they could be stolen by sniffers and used to hijack your session completely.
The Firesheep proof-of-concept plugin created a huge backlash from users, who now had an easy way of understanding why “part time HTTPS” was mere cybersecurity theater – worse than useless, in fact, because it protected neither your account nor your messages, while misleadingly giving the impression of good security at login time.
As a result, HTTPS quickly became normalized and expected everywhere, to the point that many browsers today will refuse to make HTTP connections at all, unless you deliberately authorize HTTP for specific sites.
Whether you make a wired connection or a wireless connection, with or without Wi-Fi password protection, HTTPS-encrypted traffic is largely useless to snoops and attackers who are sniffing out network traffic.
End-to-end encryption such as HTTPS helps security enormously, but it doesn’t close off all the loopholes when you’re using an unknown or untrusted Wi-Fi connection.
Not all network traffic uses HTTPS, and a surprising amount of non-HTTPS traffic is still unencrypted by default, including traffic to map out the network, to check for available devices, to advertise available services, and to turn network names such as example.com into network numbers such as 198.51.100.51.
Also, allowing anyone currently connected to the same Wi-Fi network to send data directly to your computer, even if you expect your computer to reject it, opens your computer up to probes, cyberattacks, and exploits that you would be much less likely to experience at home, where there usually aren’t any strangers on the inside of your network.
By default, most Wi-Fi access points shield internal users from probes and attacks from the internet, which is why you typically need to reconfigure your home router manually to allow incoming network connections from the internet, for example to play some online games or to run a web server of your own.
On less trusted Wi-Fi networks, however, such as in shopping malls or coffee shops, early Wi-Fi access points made it possible for rogue users to map out, probe, and sniff out all other users’ devices and traffic, even if they couldn’t make sense of any packets that were end-to-end encrypted.
Although this loophole didn’t enable blanket surveillance, given that traffic such as HTTPS gets encrypted before it joins the network at all, it nevertheless introduced real dangers, such as attacks on unpatched computers, users being tricked into visiting fake sites, monitoring of traffic patterns, and the capture of unencrypted traffic for later analysis.
Recent Wi-Fi routers therefore usually implement what is known as client isolation, which aims to treat each connected device as if if were plugged directly into its own wired port on the router, and blocked by firewall rules from seeing (or being seen by) any other devices on the network at the same time.
This blocks features such as peer-to-peer connections and file sharing, because two devices on the same Wi-Fi network can’t directly communicate with one another (though they can both connect to the same external website at the same time), but that’s generally seen as an entirely acceptable price to pay for the safety and security of shielding users’ devices from unwanted probes and attacks by others on the same network.
Note that on a Wi-Fi network with no client isolation, you could be at risk from other users not because they themselves are untrustworthy or malicious , but simply because their devices have already been infected with malware that secretly mounts attacks on nearby computers. It’s not enough to trust the people around you in the coffee shop – you have to trust their computers, too.
Unfortunately, a recent paper presented at the 2026 Network and Distributed System Security (NDSS) Symposium introduced a range of attacks imaginatively dubbed AirSnitch, which showed several ways of bypassing client isolation protection, at least in part, on every Wi-Fi access point they tested:
[E]very router and network that we tested was affected by at least one of our attacks. Our attacks affect both home and enterprise networks, enabling traffic injection towards victim clients, interception of traffic sent by the victim to the Internet, and a combination of both to perform Machine-in-the-Middle (MitM) attacks.
The paper is 18 pages long, and quite technical, so we aren’t going to deconstruct or dig into it here, but we will summarize what these attacks mean for Wi-Fi security, and what you can do about it.
Notably, the researchers showed that some of the additional protection that client isolation aims to provide can be sidestepped.
The good news is that this doesn’t mean that encrypted data such as HTTPS traffic (web requests and replies) can magically be recovered, or that malware can trivially be copied onto other computers on the network, so AirSnitch isn’t a reason to stop using Wi-Fi altogether.
indeed, if you’re in the sort of environment where AirSnitch represents an irremediable danger, you probably shouldn’t be using Wi-Fi at all.
But:
As the researchers point out, even though the scope of each of these these tricks is limited, and doesn’t automatically open up devices on the Wi-Fi network to surveillance and malware attack, these four problems could, in theory at least, lead to some types of MitM attack.
That’s because a MitM attack typically doesn’t just allow attackers to snoop on your traffic, but also to modify it along the way, potentially misleading you by luring you to the wrong site or manipulating your own view of the network.
As we mentioned above, even though this research shows that existing Wi-Fi client isolation tools need improvement, the possible attacks it introduces don’t mean that Wi-Fi networks are now inherently unsafe to use.
Importantly, end-to-end encryption, where traffic is encrypted before it is transmitted on the network at all, and only decrypted when it reaches its final destination, is not at risk of snooping or of unauthorized modification.
HTTPS traffic, which you should use whenever you can, still gets encrypted inside your browser, and only decrypted when it’s being processed by the web server it was sent to, as generally happens when you use HTTPS; likewise, apps that implement their own end-to-end encryption still provide the anti-snooping protection that they did before.
Also, the researchers note that they submitted their findings privately to affected vendors, and waited more than 90 days, a generally-accepted length of time for what’s called responsible disclosure, before publishing their results.
As the researchers state, “[m]ost vendors have responded and sought co-operation, and several have already issued software updates.”
Nevertheless, this story is a great reminder that cybersecurity really is a journey, not a destination, and that even long-standing and widely-used defenses may need adapting as new attacks or weaknesses are discovered.
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Featured image of Wi-Fi sign in Milano by Joshi Milestoner via Unsplash.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
