What 802.1X Actually Proves, and the Checkbox That Decides It

A company laptop joins the office network with the same credentials the user types into everything else, and nobody thinks about it again. The mechanism underneath is 802.1X, and it has a specific asymmetry worth knowing: it is very good at proving who the client is, and it proves who the network is only if the client was configured to check. That configuration is one screen most deployments skip.

The home Wi-Fi model is a shared secret. Everyone who knows the passphrase derives the same key material, and the access point cannot tell one person from another. Enterprise Wi-Fi replaces that with a per-user authentication exchange, standardised as IEEE 802.1X, and it introduces three parties instead of two.

The supplicant is the software on the client device. The authenticator is the access point or switch, which starts out passing nothing but authentication traffic and opens the port once the exchange succeeds. The authentication server is a RADIUS server holding the actual user database. The access point is a relay in this design. It never sees the credential and never decides anything.

What travels between supplicant and authentication server is the Extensible Authentication Protocol (RFC 3748), which is not an authentication method at all. EAP is a container. The method inside it is negotiated, and the choice of method is where deployments diverge sharply in what they actually guarantee.

The methods, and what each one proves

Two families, then. Certificate-based methods where the client holds a private key, and tunnelled password methods where the client holds something a person can type. The second family carries the deployment problem, and it is by far the more common of the two.

Why the inner password method matters less than it should

MS-CHAPv2 is a challenge-response protocol from the era of dial-up. In 2012 Moxie Marlinspike and David Hulton demonstrated that its security reduces to a single DES operation. The protocol splits the NT hash into three chunks and encrypts the same challenge under each; the third chunk is padded with five zero bytes, which makes it trivially recoverable, and the remaining work is one exhaustive DES keyspace search. Purpose-built hardware turned that into a bounded, predictable job. The correct summary since then is that a captured MS-CHAPv2 exchange yields the NT hash, and the NT hash is the credential.

This is survivable, because in PEAP the MS-CHAPv2 exchange happens inside a TLS tunnel. An observer on the air sees ciphertext. The entire security of the arrangement therefore rests on one question: did the client verify that the TLS tunnel terminated at the organisation's RADIUS server, and not at a laptop in the car park?

The two settings that carry the weight

A correctly configured PEAP client pins two things: the certificate authority that signed the RADIUS server certificate, and the expected server name on that certificate. Pinning only the CA is not enough if the CA is a public one, because anyone can obtain a certificate from it. Both fields, together, are what make the tunnel meaningful.

When those fields are blank, the client accepts any certificate, completes a tunnel with whoever answered, and hands over an MS-CHAPv2 exchange for a domain account. Tools that automate this have existed for over a decade. The attack needs no interaction from the user beyond being in range of a stronger signal with a matching network name, which is the same premise as an ordinary evil twin but with a much better prize at the end.

How the ecosystem responded

Client platforms have been closing the gap by removing the option to be wrong. Android 11 dropped the "do not validate" choice for enterprise networks, requiring either a specified CA certificate with a domain, or explicit use of the system trust store with a domain. WPA3-Enterprise in its 192-bit mode requires server certificate validation and constrains the cipher suites. Configuration profiles, whether pushed by MDM or by a provisioning tool such as the one eduroam publishes, exist mainly so that the CA and server name fields are never left to the person joining the network.

The practical consequence for anyone specifying a deployment: PEAP is acceptable only alongside a mechanism that guarantees the client configuration. If users join by typing a network name and a password, the certificate check is not happening on some fraction of devices, and that fraction is where the credentials leave.

RADIUS itself is older than the threat model

Behind the access point, the authenticator talks to the authentication server over RADIUS (RFC 2865), a protocol from 1997 that runs over UDP and authenticates its packets with an MD5-based construction and a shared secret. The User-Password attribute is obscured with an MD5 stream, and everything else in the packet, including usernames and the accounting record of who connected from where and for how long, is plaintext on the wire.

In July 2024 a research team published Blast-RADIUS (CVE-2024-3596), which turns MD5 chosen-prefix collisions into a forgery of the Access-Accept response. An attacker positioned between the authenticator and the RADIUS server can convert a rejection into an acceptance without knowing the shared secret. The mitigations are the Message-Authenticator attribute enforced on both ends, and, more durably, moving RADIUS inside TLS with RadSec (RFC 6614).

EAP-TLS traffic is not affected by the response forgery in the same way, because the client has already completed a mutual handshake and derived keys with the server it verified. Protocol choices that establish keys between the endpoints tend to age better than protocol choices that trust an intermediate result.

What certificate-based authentication changes

EAP-TLS removes the password from the exchange entirely. The client holds a private key that never leaves the device, ideally in a TPM or secure element, and the network holds a public certificate. There is nothing to phish, nothing to reuse on another service, and nothing an evil twin can capture and crack offline, because the client will not complete a handshake with a server whose certificate does not chain to the expected authority.

The cost is that somebody has to run a certificate authority, enrol every device, handle renewal before expiry, and maintain revocation. That is real operational work, and it is the reason PEAP persists. It is also work that pays for itself in adjacent places, since the same enrolment can serve mutual TLS for internal services and SSH certificates for administrative access.

What 802.1X does not do

Network authentication decides who may send packets. It does not encrypt anything above the link layer, and it does not conceal traffic from the network operator, who is now in a stronger position than before, because every session is tied to a named account rather than to a device that shares one key with everyone else. On a corporate network, the accounting records generated by RADIUS are a per-user log of connection times and access point locations, which is an access log with a floor plan attached.

For a guest or a personal device, the useful posture is the same one that applies to any untrusted network: assume the operator sees traffic metadata, and rely on transport encryption end to end rather than on the link. Enterprise Wi-Fi raises the bar for an outsider on the airwaves. It does not change what the network's own operator can observe, and it is not designed to.

A short checklist

• Prefer EAP-TLS where device enrolment is feasible. It removes the credential class that evil twins exist to collect.
• If PEAP, distribute configuration. Set the CA and the server name by profile, not by instruction. A screenshot in a wiki page is not a control.
• Use a private CA for the RADIUS certificate, or pin the server name precisely. A public CA plus a blank name field is close to no check at all.
• Enforce Message-Authenticator on RADIUS, and move to RadSec where the software supports it.
• Set a retention period on accounting logs before the first one is written, not after somebody asks for two years of them.

The pattern here recurs across security protocols. A design offers mutual authentication, one direction is mandatory and the other is a client-side setting, and the optional direction is the one that gets skipped at scale. Certificate validation in TLS went through the same history before browsers made failure loud. Enterprise Wi-Fi is a few years behind on the same curve, and the platforms removing the "do not validate" checkbox are what moves it forward.

Originally published at havenmessenger.com