Evil Twin Eap Tls

Evil Twin EAP-TLS Assessment

This skill guides security professionals through assessing EAP-TLS enterprise WiFi deployments for Evil Twin vulnerabilities. EAP-TLS is the "secure" choice for WPA2/3-Enterprise, but two practical weaknesses regularly appear during assessments:

1. Unauthenticated identity leakage: The outer EAP-Response/Identity is sent in cleartext before any TLS tunnel is built, so real domain usernames often leak over the air.
2. Broken client server-validation: If the supplicant doesn't strictly verify the RADIUS server certificate (or allows users to click through warnings), a rogue AP with a self-signed cert can still onboard victims.

Quick Start

# Harvest EAP identities from a target network
./scripts/harvest-eap-identities.sh $IFACE $CHAN $BSSID

# Probe client TLS version tolerance
./scripts/probe-tls-versions.sh $IFACE $SSID

# Generate hostapd-wpe config for TLS 1.2 downgrade
./scripts/generate-evil-twin-config.sh --tls-version 1.2 --force-authorized

Attack Methodology

1. Passive Identity Harvesting

EAP drives an identity exchange before TLS starts. If the client uses the real domain username as its outer identity, anyone in RF range can harvest it without authenticating.

Workflow:

1. Park on the target channel/BSSID
2. Decode EAP frames and extract identities
3. Trigger a client connection to observe the leak

Commands:

# Monitor the target AP
airodump-ng -i $IFACE -c $CHAN --bssid $BSSID

# Extract EAP identities from captures
tshark -i "$IFACE" -Y eap -V | grep "Identity: *[a-z]\|*[A-Z]\|*[0-9]"

Impact: Fast, no-auth username collection fuels password spraying, phishing, and account correlation. Worse when usernames match email addresses.

2. TLS 1.3 Downgrade Exploitation

TLS 1.3 encrypts client certs and most handshake metadata. When a supplicant actually negotiates TLS 1.3, an Evil Twin cannot passively learn the client certificate/identity. However, many enterprise stacks still allow TLS 1.2 for compatibility.

RFC 9190 Warning: A rogue AP can offer only TLS 1.2 static-RSA suites to force a fallback and re-expose the outer identity (or even the client cert) in cleartext EAP-TLS.

Offensive Playbook:

1. Compile hostapd-wpe with only TLS 1.2 static RSA ciphers enabled
2. Advertise the corporate SSID
3. When the victim initiates TLS 1.3, respond with a TLS alert and restart the handshake
4. The peer retries with TLS 1.2, revealing its real identity before cert validation succeeds
5. Pair with force_authorized=1 in hostapd-wpe so the 4-way handshake completes even if client-auth fails

Configuration for TLS 1.2 Downgrade:

# hostapd-wpe.conf
ssl_ctx_flags=0
openssl_ciphers=RSA+AES:@SECLEVEL=0   # requires OpenSSL 1.1.1
disable_tlsv1_3=1
force_authorized=1

Probe Client TLS Intolerance:

Run two rogues:

• One advertising TLS 1.3-only (disable_tlsv1=1, disable_tlsv1_1=1, disable_tlsv1_2=1)
• One TLS 1.2-only

Clients that only join the 1.2 BSS are downgradeable.

Watch for Fallback in Captures:

Filter in Wireshark for tls.handshake.version==0x0303 after an initial ClientHello with supported_versions containing 0x0304. Victims that retry 0x0303 are leaking their outer ID again.

3. Evil Twin via Broken Server Validation

Rogue APs broadcasting the corporate SSID can present any certificate. If the client doesn't validate the server cert or prompts the user and allows override of untrusted CAs/self-signed certs, then EAP-TLS stops being mutual.

Rogue Infrastructure Setup:

On recent Kali, compile hostapd-wpe using hostapd-2.6 and install legacy OpenSSL headers:

apt-get install libssl1.0-dev
# patch hostapd-wpe to set verify_peer=0 in SSL_set_verify to accept any client cert

A modified hostapd/hostapd-wpe that skips client-cert validation (e.g., SSL_set_verify(..., 0)) is enough to stand up the Evil Twin.

Windows Supplicant Assessment

Key Configuration Knobs

From the Windows EAP-TLS profile:

Observed Outcomes

TLS 1.3 Realities (2024-2025)

• FreeRADIUS 3.0.23+ accepts EAP-TLS 1.3, but clients still break (Windows 11 has no EAP-TLS 1.3 session resumption, Android support varies), so many deployments pin tls_max_version = "1.2" for stability
• Windows 11 enables EAP-TLS 1.3 by default (22H2+), yet failed resumptions and flaky RADIUS stacks often force a fallback to TLS 1.2
• RSA key exchange for TLS 1.2 is being deprecated; OpenSSL 3.x drops static-RSA suites at security level ≥2, so a TLS 1.2 static-RSA rogue needs OpenSSL 1.1.1 with @SECLEVEL=0 or older

Defensive Assessment Checklist

• Check if phase1="tls_disable_tlsv1_3=0" is enabled on clients (removes downgrade window)
• Verify Windows profiles have "Verify the server's identity" checked
• Confirm "Connect to these servers" has specific CN/SAN pins, not empty
• Ensure "Don't prompt user" is checked to prevent click-through
• Review RADIUS server TLS version configuration
• Check for TLS 1.2 static-RSA cipher usage in the environment

References

• EAP-TLS: The most secure option? (NCC Group)
• EAP-TLS wireless infrastructure (Versprite hostapd bypass)
• RFC 4282 - Network Access Identifier
• Microsoft ServerValidationParameters (WLAN profile)
• RFC 9190 – EAP-TLS 1.3
• hostapd/wpa_supplicant 2.10 release notes (TLS 1.3 EAP-TLS support)
• FreeRADIUS TLS 1.3 support thread (Nov 2024)
• Windows 11 enabling TLS 1.3 for EAP (SecurityBoulevard, Jan 2024)
• draft-ietf-tls-deprecate-obsolete-kex