Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was discussing with a colleague today and he seemed to think that if you use 802.1X it allows users to realise if they are connecting to a rogue access point.

I dont understand this though, surely if you believe a rogue access point was the genuine one from the beginning, you would just be authenticating to a rogue radius server, instead of the original?

I dont see how 802.1X can stop you from connecting to the false network?

share|improve this question

802.1X authentication (and the subsequent WPA key generation) involves three entities: A supplicant (the client), an authenticator (the access point) and an authentication server.

Like Zoredache said, the communication between the client and the authentication server is protected by public key cryptography (at least if you use EAP-TTLS or EAP-PEAP). It's not possible to pose as the original authentication server.

However, there is no direct authentication of the AP (the authenticator, in 802.1X language) to the client (the supplicant), or the reverse. The authenticator is only relaying messages between the supplicant and the authenticating server; all the fancy public key cryptography and mutual authentication provided by some EAP methods is transparent to the authenticator, and could therefore theoretically be intercepted and replayed by a rogue access point (MITM).

With basic 802.1X, there is indeed no protection against rogue authenticators - but 802.1X, when used for "WPA enterprise encryption" (EAP), provides additional security:

The WPA encryption key (which, among other things, enables mutual authentication between client and AP - which is what you want to protect against rogue APs!) for the connection is not generated by the access point, but by the authentication server, and is relayed to the client over the secured inner EAP channel. Of course, for the access point (=authenticator) to communicate with the client, it has to know about the key too, but it gets the key from the authentication server, and not the client.

In a normal configuration, the server will not accept authentication requests by any third parties; it usually only communicates with a limited set of authenticators, and the communication is usually encrypted (by a pairwise RADIUS secret). So for a MITM to successfully imitate a proper access point, the attacker would have to imitate the role of a valid access point against the authentication server.

Long story short, the protection against rogue APs is as good as the authentication and encryption between the authenticators (e.g. the APs) and the authentication server.

If you were to create a rogue AP, you could actually succeed in relaying the 802.1X authentication; however, you would not be able to read any of the clients traffic, as that would be encrypted with a WPA key unknown to you. Likewise, anything sent to the client by your rogue AP would be rejected by the client, as the WPA key is also used for message authentication.

share|improve this answer

The 802.1x allows for mutual authentication using PKI in some configurations. This can use TLS, which is the protocol used for secure web browsing.

Both the client and AP have a private/public key-pair. The public keys are included in a certificate that is cryptographically signed by a third system that is configured to be trusted on both the client and AP. As long as the private keys and the and the CA is not compromised both machines can use the protocol to mutually authenticate each other.

The downside is that managing all the PKI takes a lot more effort then a simple shared key.

share|improve this answer
Ok but are you assuming the client selects the correct AP? If they select the wrong AP/network, then it all falls apart? – Jason Jan 7 '12 at 16:50
A rogue. AP would not have a valid certificate signed be the CA. – Zoredache Jan 7 '12 at 19:31
The AP is not the authentication server, and only the authentication server knows the certificate. – lxgr May 10 '12 at 16:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.