Evil Twin EAP-TLS
Tip
Impara e pratica il hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP:HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.
EAP-TLS è la scelta “secure” comune per WPA2/3-Enterprise, ma due debolezze pratiche si presentano regolarmente durante le valutazioni:
- Unauthenticated identity leakage: l’outer EAP-Response/Identity viene inviato in cleartext prima che venga stabilito qualsiasi TLS tunnel, quindi i real domain usernames spesso leak over the air.
- Broken client server-validation: se il supplicant non verifica rigorosamente il certificato del server RADIUS (o permette agli utenti di click through warnings), un rogue AP con un certificato self-signed può comunque onboard victims – trasformando mutual TLS in one-way TLS.
Unauthenticated EAP identity leakage / username enumeration
EAP avvia uno scambio di identity prima che TLS inizi. Se il client usa il real domain username come outer identity, chiunque in RF range può harvestarlo senza autenticarsi.
Passive harvest workflow
# 1) Park on the right channel/BSSID
airodump-ng -i $IFACE -c $CHAN --bssid $BSSID
# 2) Decode EAP frames and extract identities
# Trigger a client connection (e.g., your phone) to see the leak
tshark -i "$IFACE" -Y eap -V | grep "Identity: *[a-z]\|*[A-Z]\|*[0-9]"
Impatto: raccolta rapida di username no-auth → alimenta password spraying, phishing, account correlation. Peggio quando gli username corrispondono a indirizzi email.
TLS 1.3 privacy vs downgrade games
TLS 1.3 cifra i client certs e la maggior parte dei handshake metadata, quindi quando un supplicant effettivamente negozia TLS 1.3, un Evil Twin non può apprendere passivamente il client certificate/identity. Molti stack enterprise permettono ancora TLS 1.2 per compatibilità; RFC 9190 avverte che un rogue AP può offrire solo suite TLS 1.2 static-RSA per forzare un fallback e riesporre l’outer identity (o persino il client cert) in cleartext EAP-TLS.
Offensive playbook (downgrade to leak ID):
- Compila hostapd-wpe con solo i cipher TLS 1.2 static RSA abilitati e TLS 1.3 disabilitato in
openssl_ciphersuite/ssl_ctx_flags. - Pubblica l’SSID corporate; quando la vittima avvia TLS 1.3, rispondi con un TLS alert e riavvia il handshake in modo che il peer ritenti con TLS 1.2, rivelando la sua real identity prima che la cert validation abbia successo.
- Abbina questo con
force_authorized=1in hostapd-wpe in modo che il 4-way handshake si completi anche se la client-auth fallisce, dandoti traffico a livello DHCP/DNS per phishing o captive portal.
Defensive toggle (what to look for during an assessment):
- hostapd/wpa_supplicant 2.10 ha aggiunto il supporto EAP-TLS sia server che peer per TLS 1.3 ma lo distribuisce disabilitato di default; abilitarlo sui client con
phase1="tls_disable_tlsv1_3=0"rimuove la finestra di downgrade.
TLS 1.3 realities in 2024–2025
- FreeRADIUS 3.0.23+ accetta EAP-TLS 1.3, ma i client continuano a rompersi (Windows 11 non ha EAP-TLS 1.3 session resumption, il supporto Android varia), quindi molte deployment fissano
tls_max_version = "1.2"per stabilità. - Windows 11 abilita EAP-TLS 1.3 di default (22H2+), tuttavia resumptions fallite e RADIUS stacks instabili spesso forzano un fallback a TLS 1.2.
- Lo scambio chiave RSA per TLS 1.2 è in fase di deprecazione; OpenSSL 3.x rimuove le suite static-RSA a security level ≥2, quindi un rogue TLS 1.2 static-RSA necessita OpenSSL 1.1.1 con
@SECLEVEL=0o una versione più vecchia.
Practical version steering during an engagement
- Force TLS 1.2 on the rogue (to leak identities):
# hostapd-wpe.conf
ssl_ctx_flags=0
openssl_ciphers=RSA+AES:@SECLEVEL=0 # requires OpenSSL 1.1.1
disable_tlsv1_3=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) and one TLS 1.2-only. Clients that only join the 1.2 BSS are downgradeable. - Watch for fallback in captures: filtra in Wireshark per
tls.handshake.version==0x0303dopo unClientHelloiniziale consupported_versionscontenente 0x0304; vittime che ritentano 0x0303 are leaking their outer ID again.
Evil Twin via broken server validation (“mTLS?”)
Rogue AP che pubblicano l’SSID corporate possono presentare qualsiasi certificato. Se il client:
- non valida il server cert, o
- mostra un prompt all’utente e consente l’override di untrusted CAs/self-signed certs,
allora EAP-TLS smette di essere mutual. Un hostapd/hostapd-wpe modificato che salta la client-cert validation (es.
SSL_set_verify(..., 0)) è sufficiente per mettere su l’Evil Twin.
Rogue infra quick note
Su Kali recente, compila hostapd-wpe usando hostapd-2.6 (da https://w1.fi/releases/) e installa prima gli header legacy di OpenSSL:
apt-get install libssl1.0-dev
# patch hostapd-wpe to set verify_peer=0 in SSL_set_verify to accept any client cert
Windows supplicant misconfig pitfalls (GUI/GPO)
Principali impostazioni del profilo EAP-TLS di Windows:
- Verify the server’s identity by validating the certificate
- Se selezionato → la catena deve essere trusted; se deselezionato → qualsiasi certificato self-signed viene accettato.
- Connect to these servers
- Vuoto → qualsiasi certificato da una CA trusted è accettato; impostare la lista CN/SAN per pinzare i nomi RADIUS attesi.
- Don’t prompt user to authorise new servers or trusted certification authorities
- Se selezionato → gli utenti non possono bypassare; se deselezionato → l’utente può fidarsi di una CA/cert non attendibile e unirsi all’rogue AP.
Risultati osservati:
- Strict validation + no prompts → certificato rogue rifiutato; Windows registra un evento e TLS fallisce (buon segnale di rilevamento).
- Validation + user prompt → accettazione dell’utente = associazione Evil Twin riuscita.
- No validation → associazione Evil Twin silenziosa con qualsiasi certificato.
Riferimenti
- EAP-TLS: The most secure option? (NCC Group)
- Infrastruttura wireless EAP-TLS (Versprite hostapd bypass)
- RFC 4282 - Network Access Identifier
- Microsoft ServerValidationParameters (WLAN profile)
- RFC 9190 – EAP-TLS 1.3
- Note di rilascio hostapd/wpa_supplicant 2.10 (TLS 1.3 EAP-TLS support)
- Discussione FreeRADIUS TLS 1.3 support (Nov 2024)
- Windows 11: abilitare TLS 1.3 per EAP (SecurityBoulevard, Jan 2024)
- draft-ietf-tls-deprecate-obsolete-kex
Tip
Impara e pratica il hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP:HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.


