This tunneling occurs by relying on asymmetric cryptography through the use of X.509 certificates installed on the RADIUS server, which are sent to the client device to begin connection setup, vonNagy says in his post. The client verifies the certificate is valid& and proceeds to establish a TLS tunnel with the server and begins using symmetric key cryptography for data encryption.

Only then, once the TLS tunnel is fully formed, do the client and server make use of the less secure protocol such as MS-CHAPv2 to authenticate the client. This exchange is fully encrypted using the symmetric keys established during tunnel setup, vonNagy says. The encryption switches from asymmetric key cryptography to symmetric key cryptography to ease processing and performance, which are much faster this way. This is fundamentally the same method used for HTTPS sessions in a web browser.

VonNagy created a to show the stages of this interaction. Reading from the top down, there is the initial association of the Wi-Fi client with the access point; then the start of the TLS tunnel negotiation between the client and RADIUS server; the creation of the tunnel between them; and then the MS-CHAPv2 challenge by RADIUS, and the corresponding, authenticating response by the Wi-Fi client.

The key link in this chain then is the mutual authentication between the RADIUS server and the wireless client, vonNagy says. The client must properly validate the RADIUS server certificate first, prior to sending its credentials to the server.

And therein lies the potential vulnerability. If the client fails to properly validate the server, then it may establish an MS-CHAPv2 session with a fake RADIUS server and send its credentials along, which could then be cracked using the exploit that was shown at Defcon, says vonNagy. This is a classic man-in-the-middle attack, with the attackers inserting their RADIUS server in the middle of a conversation between the client and the user database store (typically a directory server).