Guys, the lesson is great, but I would like to suggest two improvements:
1 - Add the “full wireless handshake”
In this image here, you share the phases “Authentication” and “Association”. But I think you should introduce the “Beacon” and “Probe” phases as well, and quickly introduce them, just like here. I’m following the CCNA 200-301 course and, at this point, beacon and probes were not introduced yet. Adding all the phases will make easier for the student to understand exactly where/when the authentication phase occurs.
2 - Improve wording
What happens when someone steals one of the wireless clients? That’s a problem because of two main reasons:
- The attacker has access to your pre-shared key and can now connect to the wireless network from any device.
- You need to configure a new pre-shared key on the AP and all wireless clients.
There are stronger authentication options where we ask users for a username and password instead. This helps. When a device is stolen, at least you can pinpoint which username was compromised and reset the password for that username. You don’t have to reset the pre-shared key and configure it on all wireless clients.
What about the AP? If you are at a hotel and see a wireless network with the name “guest,” you assume that this is the hotel’s wireless network. Anyone can configure an AP and use the SSID “guest,” though. How do you know that this is a legitimate AP, owned and operated by the hotel?
A wireless client saves a profile for all wireless networks it has connected to. When it sees the “guest” network again, it will attempt to authenticate and associate with it.
Some wireless attacks use a fake AP, called a rogue AP. The rogue AP acts just like a regular AP; it transmits beacons, answers probes, and associates clients. When a client associates with the rogue AP, the attacker sits in between the wireless and wired traffic and can intercept all traffic, just like the real AP.
To prevent this type of man-in-the-middle attack, the client should authenticate the AP before the client authenticates itself to the AP.
- In addition to the bullet point “The attacker has access to your pre-shared key and can now connect to the wireless network from any device”, I think you should add a new bullet point “Now it’s possible for the attacker to de-encrypt and then read traffic from other stations connected to the same AP”, just to make clear the limitations of this authentication method.
- When you say “To prevent this type of man-in-the-middle attack, the client should authenticate the AP before the client authenticates itself to the AP”, you do not make clear if this is valid for WPA Enterprise mode, WPA Personal mode or both.
- My understanding is that this is only valid for WPA Enterprise mode. For Personal mode, if the attacker somehow get access to the PSK and configure a fake/rogue AP with the same PSK, there is no much what the client can do. So for WPA Personal mode, it’s really necessary to protect the PSK, and in a hotel, is WPA PSK is used and the PSK is shared with everyone, someone creating a rogue AP is a real possibility/vulnerability to consider.
- If my understanding is correct, I would suggest you do edit the lesson to make clear that “server certificate validation” only applies to WPA Enterprise mode.