Can other people on an encrypted Wi-Fi AP see what you're doing?

33

15

If you connect to an open, unencrypted Wi-Fi access point, everything you do can be captured by other people within range.

If you connect to an encrypted point, then people nearby can intercept what you're doing, but can't decrypt it. The person who runs the access point can intercept what you're doing, though, right?

What about other people who know the key and are connected to the same point? Can they intercept your wireless transmissions and decrypt them? Or can they see your packets with a packet sniffer?

endolith

Posted 2010-06-25T19:30:30.233

Reputation: 6 626

2Yes we can, and I've been nominated to ask you to stop doing that!

:P – Mark Allen – 2010-06-25T20:29:02.047

1Stop checking my mail? – endolith – 2010-06-27T14:02:01.477

"AP Isolation - This isolates all wireless clients and wireless devices on your network from each other. Wireless devices will be able to communicate with the Gateway but not with each other in the network." http://tomatousb.org/settings:wireless

– endolith – 2011-06-06T15:14:49.523

my apologies, I was attempting (and as usual failing) to make a joke. This is a huge topic - practically, it's like everything else with security - nothing's perfect, the idea is to make yourself a more difficult target than the other available targets. – Mark Allen – 2011-06-10T23:33:28.373

Answers

45

Yes, with WEP encryption it's super simple. Everything's encrypted with the key you needed to know to get on the network. Everyone on the network can decode everyone else's traffic without even trying.

With WPA-PSK and WPA2-PSK, it's a little trickier, but not too hard. WPA-PSK and WPA2-PSK encrypt everything with per-client, per-session keys, but those keys are derived from the Pre-Shared Key (the PSK; the key you have to know to get on the network) plus some information exchanged in the clear when the client joins or re-joins the network. So if you know the PSK for the network, and your sniffer catches the "4-way handshake" another client does with the AP as it joins, you can decrypt all of that client's traffic. If you didn't happen to capture that client's 4-way handshake, you can send a spoofed de-authenticate packet to the target client (spoofing it to make it look like it came from the AP's MAC address), forcing the client to fall off the network and get back on, so you can capture its 4-way handshake this time, and decrypt all further traffic to/from that client. The user of the machine receiving the spoofed de-auth probably won't even notice that his laptop was off the network for a split second. Note that NO man-in-the-middle hassle is necessary for this attack. The attacker just has to capture a few specific frames at the time the target client (re-)joins the network.

With WPA-Enterprise and WPA2-Enterprise (that is, with 802.1X authentication instead of using a Pre-Shared Key), all the per-client per-session keys are derived completely independently, so there's no possibility of decoding each others' traffic. An attacker would either have to sniff your traffic on the wired side of the AP, or possibly set up a rogue AP in the hope that you'll ignore the bogus server-side certificate the rogue AP would send, and join the rogue AP anyway.

Spiff

Posted 2010-06-25T19:30:30.233

Reputation: 84 656

1WPA-PSK really doesn't use a secure key-exchange protocol to establish session keys? – hobbs – 2014-09-04T20:57:57.937

1@hobbs It's secure from outsiders who don't know the password (PSK). It's not secure from insiders who know the PSK and can already join the network, but then again, Ethernet-like LANs have long required you to trust your peers on the LAN (that they won't ARP poison you and watch all your traffic that way, for example). – Spiff – 2014-09-04T22:15:18.693

1Is this info still up do date, or have solutions been found, to shield users from each otehr, i.e. for public WiFi's ? – Frank Nocke – 2016-04-15T10:52:31.163

2@FrankN This info is still up to date. Apps that need their communications encrypted need to encrypt it themselves instead of just lazily hoping lower layers might be doing their job for them. Users that don't trust their apps should switch to better apps, but they could moderately improve their security by using VPNs. There's no viable way for public Wi-Fi operators to keep uninformed/insecure users safe, and even if you were on a public Wi-Fi that did use 802.1X or something, you should still protect yourself against someone snooping your traffic on the wired LAN one hop upstream. – Spiff – 2016-04-15T15:49:52.090

"An attacker would either have to sniff your traffic on the wired side of the AP"

Is that generally possible? That would seem to be easier than decrypting. – endolith – 2010-06-27T14:04:02.147

3Only if they have physical access to the AP. – Moab – 2010-06-28T15:23:05.607

1Or a wiring closet upstream of the AP. – Fred – 2010-07-29T19:53:49.417

@Spiff, in regards to WPA Enterprise, wouldn't you have to account for Hole196 as well as the video card farms in the cloud, maybe it is called CloudCracker.com – rjt – 2013-05-03T04:57:27.023

2

WPA at least has some form of session keys. Assuming (I'm not sure what WPA actually uses) the session keys are established using a protocol like Diffie-Hellman, they are initially secure even when the PSK is not. With the TKIP cypher session keys can be broken quickly, letting someone intercept and inject packets without knowing the pre-shared key.

However, someone who knows the PSK could just set up a rogue access point, do a man in the middle and pick their own session keys, which makes the point moot. An active attacker who knows your PSK can control the link layer, intercepting and modifying packets.

If you replace PSK authentication with IEEE 802.1X, which uses certificates and a PKI, you can trust the AP is initially the right one. A MITM would require the attacker to break clients and access point to get their private certificates, instead of just getting the PSK. The protocol seems to have a weakness that lets an attacker do a man in the middle after the initial authentication; I don't know how applicable this is to the wireless case. But people have a tendency to accept certificates blindly, and not all access points let you configure 802.1X.

Tobu

Posted 2010-06-25T19:30:30.233

Reputation: 2 584

0

Unencrypted WAP means all traffic over the wireless link can be read by anyone.

With an encrypted WAP, all traffic is encrypted on the radio link, but anyone with access to the WAP's WAN port can read the traffic even without the encryption key. With the WAP's key, for WiFi, you can read all the traffic on the radio link.

The secure way to use a shared wireless AP is by using end-to-end encryption; your traffic is encrypted before it is sent over the radio link and is not decrypted until it arrives at the destination. So, even with the WAP key or access to the WAP's WAN port, end-to-end encrypted traffic is safe.

A common way to gain end-to-end encryption is to use an encrypted VPN. The traffic using the VPN between your machine and the VPN endpoint is encrypted, and so safe.

One complication. A VPN can use a technique called split-tunneling, which means that traffic not destined for the network at the VPN's other side doesn't use the VPN. And traffic that doesn't use the VPN isn't encrypted by the VPN, so if you use split tunneling, traffic not addressed to the other end of the VPN is not protected by the VPN.

Fred

Posted 2010-06-25T19:30:30.233

Reputation: 1 205

2-1 Most of the post does not really answer the question. The part that does, namely "With the WAP's key, for WiFi, you can read all the traffic on the radio link." is wrong (this is not true for 802.1X auth, see Spiff's answer). – sleske – 2010-07-19T10:35:29.407

1The question posits the encryption key is known ("What about other people who know the key and are connected to the same point?"). With WPA-Enterprise, since there is no single key, it is reasonable to read that as "other people know the pairwise transient key of a port", and indeed, if you know the PTK, you can decrypt the traffic. – Fred – 2010-07-29T20:23:31.930