EAP-TLS vs EAP-TTLS: quale protocollo WiFi basato su certificati scegliere?

Sintesi Esecutiva

Scegliere il giusto metodo EAP per la tua implementazione 802.1X determina se il tuo WiFi aziendale è veramente sicuro o semplicemente conforme sulla carta. EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definito in RFC 5216, richiede l'autenticazione reciproca dei certificati: sia il dispositivo client che il server RADIUS presentano certificati X.509 validi prima che venga concesso l'accesso alla rete. In nessun momento vengono scambiate password. EAP-TTLS (Tunneled Transport Layer Security), definito in RFC 5281, richiede solo un certificato lato server per stabilire un tunnel TLS crittografato, all'interno del quale il client si autentica utilizzando le credenziali di directory esistenti.

Per i CTO e gli architetti di rete che gestiscono infrastrutture in catene di vendita al dettaglio, strutture ricettive e organizzazioni del settore pubblico, questa decisione si riduce a una domanda: gestisci i dispositivi? Se controlli la flotta di dispositivi tramite MDM, EAP-TLS è la scelta definitiva. Se supporti un ambiente BYOD diversificato o non disponi di una Public Key Infrastructure (PKI) robusta, EAP-TTLS offre un'alternativa pragmatica e altamente sicura. Purple supporta entrambi i percorsi di autenticazione per il Staff WiFi in oltre 80.000 sedi attive.

Approfondimento Tecnico

Architettura di EAP-TLS

EAP-TLS opera su un modello di autenticazione reciproca all'interno del framework di controllo dell'accesso basato su porta IEEE 802.1X. Ogni scambio di autenticazione coinvolge tre componenti chiave: il supplicant (dispositivo client), l'authenticator (access point wireless) e l'authentication server (server RADIUS). L'access point non prende autonomamente la decisione di autenticazione. Agisce come un relè trasparente, incapsulando i messaggi EAP in pacchetti RADIUS e inoltrandoli al server di autenticazione. L'handshake EAP-TLS procede come segue. L'access point invia un EAP-Request/Identity al dispositivo che sta tentando di connettersi. Il dispositivo risponde con la propria identità. Il server RADIUS avvia l'handshake TLS con un messaggio EAP-TLS/Start. Il client invia un ClientHello, indicando le cipher suite TLS supportate. Il server RADIUS risponde con un ServerHello, il proprio certificato server X.509 e una richiesta di certificato. Il client convalida il certificato del server rispetto al proprio archivio delle CA radice attendibili. Se la convalida non va a buon fine, l'handshake si interrompe - garantendo così protezione contro gli access point non autorizzati. Il client presenta quindi il proprio certificato X.509. Il server RADIUS convalida il certificato del client, verificando la catena di firma fino alla CA radice attendibile, confermando che il certificato non sia scaduto e controllando la lista di revoca dei certificati (CRL) o interrogando l'OCSP. L'accesso alla rete viene concesso e il tunnel TLS stabilito solo quando entrambe le parti sono verificate.

Poiché non vengono scambiate password, EAP-TLS è al sicuro da attacchi dizionario offline, credential stuffing e phishing. È l'unico metodo EAP che soddisfa i requisiti WPA3-Enterprise a 192 bit (Suite B), ed è obbligatorio o fortemente raccomandato dallo standard PCI-DSS 4.0 per gli ambienti con dati dei titolari di carta e da NIST SP 800-120 per le implementazioni wireless ad alta sicurezza.

EAP-TLS richiede una PKI. È necessaria almeno una CA radice offline e una CA emittente online. La CA radice deve essere isolata (air-gapped), poiché la sua chiave privata rappresenta l'ancora di attendibilità principale per l'intera gerarchia di certificati. La CA emittente gestisce l'emissione quotidiana dei certificati e pubblica le CRL. I certificati client vengono emessi per i singoli dispositivi, non per gli utenti - questo è un modello basato sull'identità del dispositivo. Questa distinzione è fondamentale per i dispositivi IoT, i terminali condivisi e i sistemi headless.

Struttura di EAP-TTLS

Il protocollo EAP-TTLS è stato progettato per fornire una solida sicurezza 802.1X senza l'onere operativo di dover distribuire certificati su ogni singolo dispositivo client. Funziona in due fasi. Nella prima fase, il server RADIUS presenta il proprio certificato e stabilisce un tunnel TLS sicuro. Solo il server richiede un certificato. Nella seconda fase, il client viene autorizzato all'interno di quel tunnel crittografato utilizzando un metodo di autenticazione interno. I metodi interni più comuni includono PAP (Password Authentication Protocol), CHAP e MS-CHAPv2. Il client invia il proprio nome utente e la password, ma poiché questo scambio avviene all'interno del tunnel TLS, le credenziali sono crittografate in transito e mai esposte via etere.

EAP-TTLS offre un eccellente supporto multipiattaforma su macOS, Linux, Android e iOS. L'unica eccezione riguarda Windows: il supplicant integrato di Windows non supporta nativamente EAP-TTLS per il protocollo wireless 802.1X. Gli ambienti con un volume elevato di dispositivi Windows potrebbero richiedere un supplicant di terze parti, il che aumenta la complessità operativa. Per gli ambienti incentrati su Windows, PEAP con MS-CHAPv2 rappresenta spesso la scelta più pragmatica.Il limite più grande di EAP-TTLS è che non elimina i rischi intrinseci delle password. Se un utente sceglie una password debole, questa rimane vulnerabile agli attacchi brute force offline. Se l'autenticazione interna utilizza PAP, la password viene inviata in testo non crittografato all'interno del tunnel - il che è accettabile se si fida della propria infrastruttura RADIUS, ma rimane un modello di fiducia essenziale da comprendere.

Confronto Affiancato

Guida all'Implementazione

Distribuire EAP-TLS per Flotte Gestite

La distribuzione di EAP-TLS richiede una PKI funzionante e una piattaforma MDM. L'installazione manuale del certificato non è praticabile su scala aziendale. È necessario integrare la propria PKI con il proprio MDM utilizzando SCEP (Simple Certificate Enrolment Protocol) o EST (Enrolment over Secure Transport). Quando un dispositivo aziendale viene registrato, richiede e riceve automaticamente il suo certificato senza l'intervento dell'utente.

Per la gestione delle identità, Purple funge da identity provider gratuito per servizi come OpenRoaming nell'ambito della licenza Connect, facilitando il roaming sicuro tra diverse sedi utilizzando i framework sottostanti di certificati e identità.

Sul lato RADIUS, configurare il server per convalidare i certificati client rispetto alla CA interna e verificare le CRL o utilizzare OCSP per il controllo della revoca in tempo reale. Le piattaforme RADIUS supportate includono FreeRADIUS, Microsoft NPS e Cisco ISE. L'overlay cloud di Purple si integra con l'hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Distribuire EAP-TTLS per Ambienti Misti

EAP-TTLS è la scelta ottimale per ambienti con dispositivi non gestiti. È sufficiente distribuire un certificato attendibile sul server RADIUS. Assicurarsi che il server RADIUS si integri direttamente con il servizio di directory - Microsoft Entra ID, Okta o Google Workspace - per convalidare le credenziali di autenticazione interna. Configurare i profili WiFi distribuiti tramite MDM per imporre la convalida del certificato del server rispetto alla CA attendibile specifica. Senza questo passaggio, il tunnel TLS non offre alcuna protezione contro gli access point non autorizzati.

Best Practices

Imponi la validazione del certificato del server su ogni client

Il passaggio di configurazione più critico sia per EAP-TLS che per EAP-TTLS è imporre la validazione del certificato del server sui dispositivi client. Se un dispositivo non valida il certificato del server RADIUS rispetto a una CA fidata specifica, si connetterà a qualsiasi server che presenti un certificato qualsiasi - incluso un access point canaglia. Specifica sempre la CA fidata e il nome del server previsto nei tuoi profili WiFi distribuiti tramite MDM. Questo singolo controllo di configurazione è il miglioramento della sicurezza più efficace che tu possa implementare oggi.

Automatizza la gestione del ciclo di vita dei certificati

I certificati scadono. Se non disponi di un processo di rinnovo automatizzato, dovrai affrontare guasti di autenticazione di massa quando i certificati scadono contemporaneamente. Utilizza SCEP o EST per automatizzare i rinnovi e configura gli avvisi di monitoraggio con largo anticipo rispetto alle date di scadenza. Se un dispositivo viene smarrito o un dipendente si licenzia, revoca immediatamente il certificato. Configura il tuo server RADIUS per controllare le CRL o utilizza OCSP per la validazione in tempo reale.

Segmenta la tua rete in base al metodo di autenticazione

In ambienti di grandi dimensioni o distribuiti, valuta la possibilità di eseguire entrambi i protocolli su SSID separati. I dispositivi gestiti aziendali si autenticano tramite EAP-TLS su un SSID WiFi dedicato allo staff. I contrattisti e i dispositivi BYOD si autenticano tramite EAP-TTLS su un SSID separato con un'adeguata segmentazione VLAN. Questo schema è comune nei gruppi del settore alberghiero come Premier Inn e Whitbread, dove i dispositivi del personale sono gestiti e dotati di certificati emessi, mentre l'infrastruttura per gli ospiti utilizza un percorso di autenticazione separato. Per ulteriori dettagli sull'architettura SSID, consulta la nostra guida Three SSIDs to rule them all: the WiFi design for guest, staff and IoT.

Sincronizza l'ora in tutta l'infrastruttura

La validazione dei certificati si basa su un'ora di sistema accurata. La sfasatura dell'orologio sui dispositivi client o sui server RADIUS genera errori di certificato "non ancora valido" o "scaduto" difficili da diagnosticare. Assicurati che tutti i componenti dell'infrastruttura siano sincronizzati con server NTP affidabili.

Risoluzione dei problemi e mitigazione dei rischi

Errori di CA sconosciuta (Unknown CA)

Se i log RADIUS mostrano "unknown CA", il dispositivo client non si fida della CA che ha emesso il certificato del server RADIUS. Verifica che il tuo profilo MDM includa il certificato della CA radice e che il supplicant sia configurato per fidarsi di essa. A seguito di una rotazione della CA o di un rinnovo del certificato, invia nuovamente il pacchetto CA aggiornato a tutti i dispositivi.

Disallineamento del metodo EAP

Se i dispositivi si connettono all'access point ma l'autenticazione fallisce, verifica che il metodo EAP configurato sul client corrisponda al metodo accettato dal server RADIUS. Un profilo di dispositivo impostato per EAP-TLS fallirà su un server RADIUS configurato solo per PEAP.

Errori di massa dovuti a certificati scaduti

Se un numero elevato di dispositivi non riesce ad autenticarsi contemporaneamente, verificare innanzitutto le date di scadenza dei certificati. Questa è la causa più comune di errori di massa del protocollo 802.1X nelle distribuzioni EAP-TLS. Implementa un sistema di monitoraggio che invii avvisi 60 giorni, 30 giorni e sette giorni prima della scadenza.

Errata configurazione del client RADIUS

Ogni access point o controller wireless deve essere definito come client RADIUS con l'indirizzo IP corretto e la shared secret. Eventuali discrepanze causano timeout di autenticazione che vengono spesso erroneamente attribuiti al metodo EAP. Abilita la registrazione dettagliata dei log RADIUS fin dal primo giorno. Per ulteriori indicazioni sulla risoluzione dei problemi WiFi, consulta la nostra guida Risoluzione dei problemi relativi al WiFi pubblico: come risolvere gli errori di 'Connesso, senza Internet' e di reindirizzamento della Splash Page.

Conformità e allineamento normativo

Per i CISO e gli architetti di rete, comprendere il panorama normativo è essenziale quando si sceglie tra EAP-TLS e EAP-TTLS. La scelta del metodo EAP influisce direttamente sul livello di conformità rispetto a diversi framework chiave.

PCI-DSS 4.0 (Payment Card Industry Data Security Standard) richiede una crittografia avanzata e un'autenticazione sicura per le reti wireless negli ambienti in cui vengono gestiti i dati dei titolari di carta. Il requisito 8.3 impone l'autenticazione a più fattori per tutti gli accessi al CDE, e le reti wireless interessate devono utilizzare meccanismi di autenticazione forte. EAP-TLS, con l'autenticazione reciproca basata su certificati, soddisfa pienamente questo requisito. EAP-TTLS con MS-CHAPv2 è accettabile se l'autenticazione interna è protetta in modo appropriato e viene applicata la convalida del certificato del server, ma EAP-TLS rimane la scelta più robusta e ideale in fase di audit. HIPAA (Health Insurance Portability and Accountability Act) richiede che i soggetti interessati implementino misure di salvaguardia tecnica a tutela delle informazioni sanitarie protette in formato elettronico (ePHI) trasmesse su reti di comunicazione elettronica. La HIPAA Security Rule non impone protocolli specifici, ma la necessità di crittografia e controllo degli accessi per le reti wireless che trasmettono ePHI pende fortemente a favore di EAP-TLS per le flotte di dispositivi medici gestiti e di EAP-TTLS con convalida forzata del certificato del server per i dispositivi del personale.

WPA3-Enterprise 192-bit (noto anche come Suite B o modalità CNSA) rappresenta il livello di sicurezza più elevato della certificazione WPA3 di Wi-Fi Alliance. Impone EAP-TLS come unico metodo di autenticazione consentito, richiede TLS 1.2 o versione successiva con suite di cifratura specifiche (ECDHE con P-384, AES-256-GCM) e richiede certificati ECDSA o RSA-3072. Le organizzazioni che distribuiscono WPA3-Enterprise 192-bit in ambito governativo, di difesa o per infrastrutture critiche devono utilizzare EAP-TLS. La certificazione ISO 27001 non impone protocolli specifici, ma richiede alle organizzazioni di implementare controlli di accesso adeguati per le risorse di rete. Un'implementazione 802.1X con EAP-TLS o EAP-TTLS (con convalida forzata del certificato del server) soddisfa i requisiti di controllo dell'accesso alla rete degli Allegati A.9.1 e A.13.1.

-

ROI e impatto sul business

La migrazione a EAP-TLS richiede un investimento iniziale nell'integrazione di PKI e MDM, ma elimina i costi operativi associati alla reimpostazione delle password e il rischio finanziario di violazioni della rete dovute a credenziali compromesse. Per una catena di vendita al dettaglio con 400 negozi, una singola password compromessa su una rete PSK condivisa può mettere a repentaglio l'intero patrimonio. Il protocollo EAP-TLS elimina completamente questo vettore di attacco.

Per gli ambienti multi-tenant e gli hub di trasporto, l'autenticazione sicura garantisce che solo gli utenti autorizzati accedano alla larghezza di banda della rete, ottimizzando così l'utilizzo dell'infrastruttura. L'assegnazione dinamica della VLAN tramite gli attributi dei certificati RADIUS consente una segmentazione della rete applicata per via crittografica, garantendo che i dispositivi siano posizionati sul segmento di rete corretto in base alle proprietà del certificato anziché affidarsi alla selezione dell'SSID o al filtraggio degli indirizzi MAC.

La piattaforma WiFi Analytics di Purple si integra con entrambi i percorsi di autenticazione, offrendo visibilità sul numero di dispositivi, sulla durata delle sessioni e sull'utilizzo della rete in tutto il tuo patrimonio. Per linee guida di implementazione specifiche per ogni settore, esplora le nostre risorse per Hospitality, Retail, Healthcare e Transport.