Networking – How to decrypt WPA2 encrypted packets using Wireshark

If you haven't already, read Wireshark's How To Decrypt 802.11 document on this and try decrypting the sample capture.

If you can't even get Wireshark to decrypt the frames in the example file, then you're probably running into a Wireshark bug.

Hints on seeing if you've decoded the sample file:

• You can't decode frames 3, 26, or 47; so basically, you won't see anything change in the first screenful of frames even if you're successfully decrypting things. You need to scroll down to after you see the Auth, Assoc, and EAPOL-key handshake.
• The first frame you can decode is 99 (Data, 404 bytes). Fully decrypted and decoded, it's a DHCP Request.
• Frame 102 (Data, 652 bytes) is a DHCP ACK.

Now, about decrypting your own captures:

Note that to decode WPA-PSK or WPA2-PSK frames from your own captures, you must capture all four frames of the EAPOL-key handshake, which happens right after the client associates to the AP. The AP and the client take the PSK and generate some cryptographic nonces, exchange the nonces via the EAPOL-key handshake, and then derive a one-time session key from that (the Pairwise Temporal Key, or PTK). If you don't capture that handshake, there's no way for Wireshark to learn the nonces, so there's no way for it to figure out what PTK the client and AP created for that session, so there's no way for Wireshark to decrypt that session.

You already mentioned that you didn't find any EAPOL frames in your capture. Look and see if you have the 802.11-layer Authenticate and Associate frame pairs. I'll bet you didn't get those either. The EAPOL-key handshake comes right after the Associate frame exchange.

Update: Also make sure you're capturing in promiscuous mode. 802.11 monitor mode will show you 802.11 headers and 802.11-specific frames, but it still might not show you unicasts between other devices unless you also enable promiscuous mode.

WPA (and WPA2) encrypts traffic below the level that Wireshark or similar tools capture. Those tools capture at the operating system's socket interface, not at the level of the actual network media. When you send a packet over WPA-protected WiFi, the WPA encryption isn't added until the last moment before the data is broadcast.

There might still be other encryption - for example, I could apply PGP encryption to an email and send it to SMTP server over TLS, which would be two levels of encryption... but those levels would be visible to (and, indeed, created by) the application (such as my email client). Somebody sniffing that traffic would still be able to see things like what protocol it's using (TCP, on top of IP), what port it comes from and is routing to, the destination IP address, and so on.

However, once the packet reaches the WiFi interface driver, it gets encrypted with the AES key that my machine is using for WPA. At that point, about the only things visible are the network SSID that I'm using (I think the source and destination MAC addresses may also be visible) and a vague idea of the size. Somebody without the WiFi key sniffing the network traffic using software-defined radio or a WiFi card in promiscuous mode wouldn't be able to tell the difference between my email and me sending a network ping or chatting on Skype; they wouldn't even be able to tell where the packets were going beyond the WiFi access point.