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

Questa guida fornisce un confronto definitivo tra EAP-TLS e EAP-TTLS per l'autenticazione WiFi aziendale secondo lo standard 802.1X. Spiega la differenza architetturale tra l'autenticazione reciproca tramite certificati e il tunneling dei certificati solo lato server, offrendo a responsabili IT, architetti di rete e CISO un chiaro quadro decisionale basato sulle capacità di gestione dei dispositivi e sui requisiti di conformità. Purple supporta entrambi i percorsi di autenticazione EAP-TLS e EAP-TTLS per il WiFi del personale; questa guida aiuta le organizzazioni a comprendere i compromessi infrastrutturali prima di adottare una delle due soluzioni.

📖 9 minuti di lettura📝 2,090 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

INTRO AND CONTEXT (0:00 - 2:00)

Buongiorno e benvenuti a questo briefing tecnico di Purple. Sono la vostra guida e oggi analizzeremo le differenze cruciali tra EAP-TLS e EAP-TTLS per l'autenticazione WiFi aziendale. Se siete architetti di rete, direttori IT o gestite infrastrutture per grandi spazi come catene di negozi, ospedali o stadi, questo briefing è stato progettato appositamente per voi. Andremo dritti al punto per discutere l'architettura di sicurezza, i compromessi di implementazione e come scegliere il protocollo giusto per il vostro ambiente. Entriamo subito nel vivo.

Prima di immergerci nei protocolli veri e propri, contestualizziamo lo scenario. La maggior parte delle distribuzioni WiFi aziendali odierne si affida ancora a una singola password condivisa - una Pre-Shared Key, o PSK. Ogni dispositivo sulla rete utilizza la stessa credenziale. Quando un dipendente si licenzia o un dispositivo viene smarrito, si hanno due opzioni: cambiare la password per tutti o accettare il rischio che un ex dipendente o un ladro possieda ancora credenziali valide. Nessuna delle due è accettabile per un'azienda seria.

La risposta è 802.1X, lo standard IEEE per il controllo dell'accesso alla rete basato su porta. Lo standard 802.1X fornisce a ogni dispositivo la propria credenziale di autenticazione individuale. Quando un dispositivo si connette, l'access point non concede l'accesso direttamente, ma inoltra la richiesta di autenticazione a un server RADIUS centralizzato, che verifica la credenziale e comunica all'access point se aprire la porta. Il risultato è un controllo degli accessi per singolo dispositivo, verificabile e revocabile. Questa è la base su cui si sviluppano sia EAP-TLS che EAP-TTLS.

Entrambi i protocolli sono metodi Extensible Authentication Protocol, o metodi EAP, che operano all'interno di questo framework 802.1X. La domanda non è se utilizzare il protocollo 802.1X, ma quale metodo EAP utilizzare al suo interno. Ed è proprio a questo che risponderemo oggi.

EAP-TLS TECHNICAL DEEP-DIVE (2:00 - 5:30)

Cominciamo con EAP-TLS, che sta per Transport Layer Security. Il protocollo EAP-TLS è definito nella specifica RFC 5216 ed è ampiamente considerato come lo standard di riferimento per l'autenticazione wireless. Il principio fondamentale è l'autenticazione reciproca. Sia il dispositivo client che il server RADIUS devono presentare certificati digitali X.509 validi per dimostrare la propria identità prima che venga concesso l'accesso alla rete. Non ci sono password coinvolte in nessuna fase del processo. Zero.

Questo aspetto è estremamente importante dal punto di vista della sicurezza. Le password possono essere rubate tramite phishing, possono essere indovinate tramite attacchi brute force o possono essere sottratte in seguito a una violazione dei dati presso un servizio terzo in cui il dipendente ha riutilizzato la stessa password. I certificati non possono essere carpiti tramite phishing, non possono essere indovinati e sono legati a un dispositivo specifico. Se un malintenzionato vuole accedere alla vostra rete, ha bisogno del dispositivo fisico e della sua chiave privata crittografica integrata. Si tratta di un modello di minaccia fondamentalmente diverso.

Lascia che ti illustri nel dettaglio l'handshake EAP-TLS, perché comprenderlo chiarisce il motivo per cui il protocollo è così sicuro. Quando un dispositivo tenta di connettersi alla rete WiFi, l'access point invia una richiesta EAP-Request per l'identità del dispositivo. Il dispositivo risponde. L'access point inoltra la risposta al server RADIUS. Il server RADIUS avvia l'handshake TLS inviando un messaggio Server Hello, insieme al suo certificato X.509. Il client convalida questo certificato del server rispetto al suo archivio di Certification Authority radice attendibili. Se la convalida fallisce, l'handshake si interrompe immediatamente. Il dispositivo rifiuta di connettersi. Questo è ciò che protegge dagli attacchi Evil Twin, in cui un hacker configura un access point fittizio per impersonare la tua rete.

Se il certificato del server è valido, il client presenta il proprio certificato X.509 al server RADIUS. Il server RADIUS convalida il certificato del client: controlla la catena delle firme fino alla CA radice attendibile, verifica che il certificato non sia scaduto e controlla la Certificate Revocation List per assicurarsi che il certificato non sia stato revocato. Solo quando entrambe le parti sono soddisfatte viene stabilito il tunnel TLS e viene inviato il messaggio EAP-Success, concedendo l'accesso alla rete. L'intero scambio utilizza TLS 1.2 o 1.3, fornendo una perfect forward secrecy.

Ora, questo livello di sicurezza comporta un requisito operativo: è necessaria una Public Key Infrastructure, o PKI. Come minimo, occorrono una Certification Authority radice offline e una Certification Authority di emissione online. La CA radice dovrebbe essere isolata fisicamente (air-gapped), perché la sua chiave privata è l'ancora di attendibilità master per l'intera gerarchia dei certificati. La CA di emissione gestisce l'emissione quotidiana dei certificati e pubblica la Certificate Revocation List. E, aspetto fondamentale, serve un meccanismo per distribuire i certificati client a ogni dispositivo sulla rete. Per una flotta di migliaia di dispositivi, questo significa integrare la tua PKI con una piattaforma di Mobile Device Management utilizzando SCEP - il Simple Certificate Enrolment Protocol. Quando un dispositivo aziendale viene registrato nel tuo MDM, richiede e riceve automaticamente il suo certificato senza alcuna interazione da parte dell'utente.

SCENARI DI IMPLEMENTAZIONE (5:30 - 8:00)

Quindi, quale protocollo dovresti implementare? La decisione dipende quasi interamente dalle tue capacità di gestione dei dispositivi e dai tuoi requisiti di conformità. Ti offro uno schema decisionale pratico.

Ponti tre domande. Primo: tutti i dispositivi che si connettono a questa rete sono gestiti a livello aziendale tramite una piattaforma MDM come Microsoft Intune o Jamf? Se sì, hai l'infrastruttura per distribuire i certificati client e EAP-TLS è la scelta giusta. Secondo: questa rete deve soddisfare i requisiti PCI-DSS 4.0, HIPAA o WPA3 Enterprise a 192 bit? Se sì, EAP-TLS è la scelta obbligata. Terzo: hai una percentuale significativa di dispositivi non gestiti o BYOD? Se sì, EAP-TTLS è la scelta pragmatica per quel segmento della tua rete.

Lasciate che vi presenti due scenari reali e concreti. Scenario uno: una catena retail nazionale con quattrocento negozi. Ogni terminale punto vendita e scanner palmare del personale è registrato in Microsoft Intune. La rete rientra nell'ambito dello standard PCI-DSS 4.0. In questo ambiente, si distribuisce EAP-TLS. Viene stabilita una PKI privata, si utilizza Intune per distribuire certificati client univoci su ogni dispositivo tramite SCEP e si configura il server RADIUS per controllare la Certificate Revocation List. Se un dispositivo viene rubato, si revoca il suo certificato ed esso viene rimosso dalla rete nel giro di pochi minuti. Nessuna password da reimpostare. Nessun segreto condiviso da aggiornare in quattrocento sedi.

Scenario due: un grande campus universitario con ventimila studenti che utilizzano laptop, smartphone e tablet personali. Il team IT non può installare certificati sui dispositivi personali. In questo ambiente, EAP-TTLS rappresenta la scelta pragmatica. Si installa un certificato attendibile sui server RADIUS, ci si integra con il servizio di directory dell'università e gli studenti si autenticano utilizzando le proprie credenziali esistenti all'interno del tunnel sicuro. Questa soluzione supporta Windows, macOS, Linux, Android e iOS senza richiedere alcun software aggiuntivo sul lato client.

In molte grandi aziende, la risposta in realtà è l'adozione di entrambi. Si distribuisce EAP-TLS per i dispositivi aziendali gestiti e EAP-TTLS o una rete sicura separata per collaboratori esterni, visitatori e BYOD. Questo è un modello comune nei gruppi del settore hospitality, dove i dispositivi del personale sono gestiti e dotati di certificati, mentre l'infrastruttura rivolta agli ospiti utilizza un percorso di autenticazione completamente diverso.

DOMANDE E RISPOSTE RAPIDE (8:00 - 9:00)

Permettetemi di fornire alcune risposte rapide alle domande che sentiamo più frequentemente da CTO e progettisti di rete.

Domanda uno: EAP-TLS è richiesto per WPA3 Enterprise? Se si sta implementando la suite di sicurezza a 192 bit di WPA3 Enterprise, sì, EAP-TLS è l'unico metodo consentito. È l'unico metodo EAP che soddisfa i requisiti a 192 bit di WPA3 Enterprise della Wi-Fi Alliance.

Domanda due: Possiamo usare EAP-TTLS per i dispositivi IoT? Generalmente no. I dispositivi IoT headless, come le pompe d'infusione o i sensori ambientali, di solito non dispongono dell'interfaccia per gestire metodi di autenticazione interna complessi. EAP-TLS è in realtà più adatto per l'IoT, perché è possibile fornire il certificato durante la fase di staging del dispositivo. Il dispositivo si autentica automaticamente, senza richiedere alcuna interazione da parte dell'utente.

Domanda tre: E per quanto riguarda il BYOD su una rete EAP-TLS? Per i dispositivi personali non gestiti, EAP-TLS è difficile da gestire a livello operativo. È possibile utilizzare portali di onboarding per fornire un certificato temporaneo, ma questo aumenta gli ostacoli per l'utente. Per il BYOD, EAP-TTLS o una rete ospiti dedicata con un'adeguata segmentazione rappresenta di solito la risposta corretta.

Domanda quattro: Qual è la compatibilità con i fornitori di hardware? Sia EAP-TLS che EAP-TTLS sono supportati da tutte le principali piattaforme hardware WiFi aziendali - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi. I dettagli di configurazione variano a seconda della piattaforma, ma gli standard sottostanti sono indipendenti dal fornitore.RIEPILOGO E PROSSIMI PASSI (9:00 - 10:00)

Per concludere, ecco i punti chiave da ricordare. EAP-TLS offre il massimo livello di sicurezza grazie all'autenticazione reciproca tramite certificati. Elimina completamente il rischio legato alle password ed è la scelta corretta per flotte di dispositivi gestiti e ambienti regolamentati. EAP-TTLS offre una solida sicurezza attraverso certificati lato server e tunneling crittografato delle credenziali. È la scelta ideale per ambienti BYOD o misti. Entrambi i protocolli richiedono di forzare la convalida del certificato del server su ogni client. Senza di essa, nessuno dei due protocolli ti protegge da access point non autorizzati. Inoltre, la gestione del ciclo di vita dei certificati rappresenta la principale sfida operativa di EAP-TLS - automatizzala tramite MDM e SCEP fin dal primo giorno.

I tuoi prossimi passi? Esegui un audit della tua attuale implementazione 802.1X. Se ti affidi ancora a password condivise, pianifica la tua migrazione. Verifica se i supplicant dei tuoi client convalidano il certificato del server. E se stai effettuando l'implementazione su più sedi o su un patrimonio distribuito, prendi in considerazione un servizio RADIUS ospitato nel cloud per ridurre il carico operativo. Grazie per aver seguito questo briefing tecnico di Purple. Purple supporta sia i percorsi di autenticazione EAP-TLS che EAP-TTLS per il WiFi del personale in oltre 80.000 sedi attive. Per guide all'implementazione più dettagliate e per capire come le nostre piattaforme di analisi e identità si integrano con le tue reti sicure, visita purple. .

Punti chiave

✓EAP-TLS richiede l'autenticazione reciproca dei certificati - sia il dispositivo client che il server RADIUS presentano certificati X.509. Non vengono scambiate password in alcun momento, eliminando completamente il rischio di furto delle credenziali.
✓EAP-TTLS richiede solo un certificato sul lato server per stabilire un tunnel TLS crittografato. Il client si autentica all'interno del tunnel utilizzando le credenziali di directory esistenti (nome utente e password).
✓Il fattore decisivo principale è la gestione dei dispositivi: se controlli i dispositivi tramite MDM, implementa EAP-TLS. Se supporti il BYOD o dispositivi non gestiti, implementa EAP-TTLS.
✓EAP-TLS è l'unico metodo EAP che soddisfa i requisiti a 192 bit di WPA3-Enterprise ed è fortemente raccomandato per gli ambienti con dati dei titolari di carta PCI-DSS 4.0.
✓Entrambi i protocolli richiedono che la convalida del certificato del server sia imposta su ogni dispositivo client. Senza di essa, nessuno dei due protocolli protegge dagli attacchi di tipo rogue access point - questa è la singola configurazione più importante da verificare.
✓L'automazione del ciclo di vita dei certificati tramite MDM e SCEP non è negoziabile per EAP-TLS su larga scala. La scadenza non gestita dei certificati è la causa più comune di interruzioni di massa dell'autenticazione.
✓Molte grandi aziende implementano entrambi: EAP-TLS per i dispositivi aziendali gestiti su un SSID Staff WiFi dedicato, e EAP-TTLS per i collaboratori esterni e il BYOD su un SSID separato e segmentato.

Sintesi Esecutiva

Scegliere il corretto metodo EAP per il tuo deployment 802.1X determina se il tuo WiFi aziendale sia realmente sicuro o semplicemente conforme sulla carta. EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definito in RFC 5216, richiede un'autenticazione reciproca basata su 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 sul 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 i network architect che gestiscono infrastrutture in catene di vendita al dettaglio, strutture ricettive e organizzazioni del settore pubblico, questa decisione si riduce a una sola domanda: gestite voi i dispositivi? Se controllate la flotta di dispositivi tramite MDM, EAP-TLS è la scelta definitiva. Se supportate un ambiente BYOD diversificato o non disponete di una Public Key Infrastructure (PKI) solida, EAP-TTLS offre un'alternativa pragmatica e altamente sicura. Purple supporta entrambi i percorsi di autenticazione per il WiFi del personale in oltre 80.000 sedi attive.

Analisi Tecnica Approfondita

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 fondamentali: il supplicant (dispositivo client), l'authenticator (access point wireless) e l'authentication server (server RADIUS). L'access point non prende la decisione di autenticazione in autonomia. Funge da relay 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 si connette. 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, comunicando le suite di cifratura 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 fallisce, l'handshake si interrompe - fornendo protezione contro gli access point non autorizzati. Il client presenta quindi il proprio certificato X.509. Il server RADIUS convalida il certificato del client, controllando la catena di firma fino alla CA radice attendibile, verificando che il certificato non sia scaduto e controllando la lista di revoca dei certificati (CRL) o interrogando l'OCSP. Solo quando entrambe le parti sono soddisfatte, il tunnel TLS viene stabilito e viene concesso l'accesso alla rete.

Poiché non vengono scambiate password, EAP-TLS è al sicuro da attacchi a 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 da PCI-DSS 4.0 per gli ambienti con dati dei titolari di carta e da NIST SP 800-120 per le distribuzioni WiFi ad alta sicurezza.

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

Struttura di EAP-TTLS

EAP-TTLS è stato progettato per fornire una robusta sicurezza 802.1X senza l'onere operativo di distribuire certificati su ogni 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 comuni includono PAP (Password Authentication Protocol), CHAP e MS-CHAPv2. Il client invia il proprio nome utente e password, ma poiché questo scambio avviene all'interno del tunnel TLS, le credenziali vengono crittografate in transito e non vengono mai esposte via etere.

EAP-TTLS offre un eccellente supporto multipiattaforma su macOS, Linux, Android e iOS. L'avvertenza riguarda Windows: il supplicant integrato di Windows non supporta nativamente EAP-TTLS per il WiFi 802.1X pronto all'uso. 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 è spesso la scelta più pragmatica.La limitazione principale di EAP-TTLS è che non elimina i rischi intrinseci delle password. Se un utente sceglie una password debole, questa rimane vulnerabile ad attacchi brute force offline. Se l'autenticazione interna utilizza PAP, la password viene inviata in testo normale all'interno del tunnel - il che è accettabile se si considera affidabile la propria infrastruttura RADIUS, ma rimane un modello di attendibilità essenziale da comprendere.

Confronto Diretto

Funzionalità	EAP-TLS	EAP-TTLS
Standard RFC	RFC 5216	RFC 5281
Certificato Client Richiesto	Sì	No
Certificato Server Richiesto	Sì	Sì
Modello di Autenticazione	Mutua (Entrambe le Parti)	Solo Server
Rischio Password	Nessuno - Passwordless	Password in Tunnel Crittografato
Requisito PKI	PKI Completa (Root CA + Issuing CA + MDM)	Solo Certificato Server
WPA3-Enterprise 192-bit	Metodo Richiesto	Non Supportato
Allineamento PCI-DSS 4.0	Fortemente Raccomandato	Accettabile con Autenticazione Interna Forte
Idoneità BYOD	Bassa (Richiede Certificato Client)	Alta (Solo Credenziali)
Idoneità Dispositivi IoT	Alta (Certificato Configurato in Staging)	Bassa (Nessuna UI per Inserimento Credenziali)
Supporto Nativo Windows	Sì	Parziale (Spesso Richiede Supplicant di Terze Parti)
Supporto macOS/Linux/Android	Sì	Sì
Complessità di Distribuzione	Alta	Media

Guida all'Implementazione

Distribuzione di 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 PKI con l'MDM utilizzando SCEP (Simple Certificate Enrolment Protocol) o EST (Enrolment over Secure Transport). Quando un dispositivo aziendale viene registrato, richiede e riceve automaticamente il proprio certificato senza l'intervento dell'utente.

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

Sul lato RADIUS, configura il tuo 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 Networks e Fortinet.

Distribuzione di EAP-TTLS per Ambienti Misti

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

Best Practice

Imporre la validazione del certificato del server su ogni client

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

Automatizzare la gestione del ciclo di vita dei certificati

I certificati scadono. Se non disponi di un processo di rinnovo automatizzato, dovrai affrontare errori di autenticazione di massa quando i certificati scadono simultaneamente. 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.

Segmentare la rete in base al metodo di autenticazione

In ambienti grandi o distribuiti, prendi in considerazione l'esecuzione di entrambi i protocolli su SSID separati. I dispositivi aziendali gestiti 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'opportuna segmentazione VLAN. Questo modello è comune nei gruppi del settore alberghiero come Premier Inn e Whitbread, dove i dispositivi del personale sono gestiti e dotati di certificati, mentre l'infrastruttura per gli ospiti utilizza un percorso di autenticazione separato. Per ulteriori dettagli sull'architettura SSID, consulta la nostra guida Tre SSID per domarli tutti: il design WiFi per ospiti, staff e IoT .

Sincronizzare l'ora in tutta l'infrastruttura

La validazione del certificato 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

Se i log RADIUS mostrano "CA sconosciuta", il dispositivo client non considera attendibile la 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 ritenerlo attendibile. A seguito di una rotazione della CA o del rinnovo di un certificato, invia nuovamente il bundle CA aggiornato a tutti i dispositivi.

Mancata corrispondenza del metodo EAP

Se i dispositivi si connettono all'access point ma l'autenticazione non va a buon fine, verificare che il metodo EAP configurato sul client corrisponda a quello 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 gran numero di dispositivi non riesce a eseguire l'autenticazione contemporaneamente, verificare innanzitutto le date di scadenza dei certificati. Questa è la causa più comune di guasti di massa del protocollo 802.1X nelle distribuzioni EAP-TLS. Implementare un sistema di monitoraggio che invii avvisi 60 giorni, 30 giorni e sette giorni prima della scadenza.

Errore di configurazione del client RADIUS

Ogni access point o controller wireless deve essere definito come client RADIUS con l'indirizzo IP corretto e la chiave segreta condivisa. Eventuali discrepanze causano timeout di autenticazione che vengono spesso erroneamente attribuiti al metodo EAP. Abilitare la registrazione dettagliata di RADIUS fin dal primo giorno. Per ulteriori indicazioni sulla risoluzione dei problemi WiFi, consultare la nostra guida Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures .

Conformità e allineamento normativo

Per i CISO e gli architetti di rete, comprendere lo scenario normativo è fondamentale quando si sceglie tra EAP-TLS ed EAP-TTLS. La scelta del metodo EAP influisce direttamente sulla postura di conformità all'interno di diversi framework chiave.

PCI-DSS 4.0 (Payment Card Industry Data Security Standard) richiede un'autenticazione crittografica forte per le reti wireless negli ambienti dei 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 incluse nel campo di applicazione devono utilizzare meccanismi di autenticazione forte. EAP-TLS, con autenticazione reciproca basata su certificati, soddisfa in modo definitivo 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 rappresenta la scelta più robusta e ideale per gli audit. HIPAA (Health Insurance Portability and Accountability Act) richiede ai soggetti coperti di implementare misure di sicurezza tecniche che proteggano le informazioni sanitarie protette elettroniche (ePHI) trasmesse su reti di comunicazione elettronica. La regola di sicurezza HIPAA non impone protocolli specifici, ma l'esigenza di crittografia e controllo degli accessi per le reti wireless che trasportano ePHI propende fortemente a favore di EAP-TLS per le flotte di dispositivi medici gestiti ed EAP-TTLS con convalida forzata del certificato del server per i dispositivi del personale. WPA3-Enterprise 192-bit (noto anche come modalità Suite B o CNSA) rappresenta il livello di sicurezza più elevato della certificazione WPA3 della Wi-Fi Alliance. Impone EAP-TLS come unico metodo di autenticazione consentito, richiede TLS 1.2 o superiore con suite di cifratura specifiche (ECDHE con P-384, AES-256-GCM) e richiede certificati ECDSA o RSA-3072. Le organizzazioni che implementano WPA3-Enterprise 192-bit per applicazioni governative, di difesa o per infrastrutture critiche devono utilizzare EAP-TLS. ISO 27001 non impone protocolli specifici, ma richiede alle organizzazioni di implementare controlli di accesso adeguati per le risorse di rete. Una distribuzione 802.1X con EAP-TLS o EAP-TTLS (con convalida forzata del certificato del server) soddisfa i requisiti di controllo dell'accesso alla rete dell'Allegato 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 legati al ripristino 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. 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 crittograficamente, garantendo che i dispositivi siano posizionati sul segmento di rete corretto in base alle proprietà del certificato anziché affidarsi alla selezione del SSID o al filtraggio degli indirizzi MAC.

La piattaforma WiFi Analytics di Purple si integra con entrambi i percorsi di autenticazione, fornendo visibilità sul numero di dispositivi, sulla durata delle sessioni e sull'utilizzo della rete in tutto il vostro patrimonio. Per una guida all'implementazione specifica per settore, esplorate le nostre risorse per Hospitality , Retail , Healthcare e Transport .

Definizioni chiave

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Un metodo di autenticazione 802.1X definito nella RFC 5216 che richiede sia al dispositivo client che al server RADIUS di presentare certificati X.509 validi. Non vengono scambiate password. L'autenticazione è reciproca e vincolata crittograficamente.

Il gold standard per la sicurezza wireless aziendale. Richiesto per WPA3-Enterprise a 192 bit e fortemente raccomandato per gli ambienti di dati dei titolari di carta PCI-DSS 4.0.

EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security)

Un metodo di autenticazione 802.1X definito nella RFC 5281 che richiede solo un certificato lato server per stabilire un tunnel TLS crittografato. Il client si autentica all'interno del tunnel utilizzando un metodo di autenticazione interno secondario, in genere un nome utente e una password.

La scelta preferita per gli ambienti BYOD e le reti con sistemi operativi misti dove l'implementazione di certificati client è operativamente impraticabile.

802.1X

Uno standard IEEE per il controllo dell'accesso alla rete basato su porta che fornisce un meccanismo di autenticazione per i dispositivi che si connettono a una LAN o WLAN. Definisce i ruoli di supplicant, authenticator e server di autenticazione.

Il framework fondamentale che consente alle reti aziendali di autenticare i singoli dispositivi invece di affidarsi a una singola password condivisa. Sia EAP-TLS che EAP-TTLS operano all'interno di questo framework.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e tracciamento per gli utenti che si connettono a un servizio di rete. Nelle implementazioni 802.1X, il server RADIUS è il server di autenticazione che verifica i certificati o le credenziali.

Il componente server che verifica i certificati o le password e indica all'access point se concedere o negare l'accesso alla rete. Le piattaforme supportate includono FreeRADIUS, Microsoft NPS e Cisco ISE.

PKI (Public Key Infrastructure)

Un insieme di ruoli, criteri, hardware, software e procedure necessari per creare, gestire, distribuire, utilizzare, memorizzare e revocare certificati digitali. Una tipica PKI aziendale è costituita da una CA root offline e da una CA emittente online.

L'infrastruttura backend richiesta per emettere i certificati client e server utilizzati nell'autenticazione EAP-TLS. Senza una PKI, non è possibile distribuire EAP-TLS.

MDM (Mobile Device Management)

Software utilizzato dai dipartimenti IT per monitorare, gestire e proteggere i dispositivi mobili e i laptop dei dipendenti. Le piattaforme MDM come Microsoft Intune e Jamf possono automatizzare la distribuzione di certificati e profili WiFi sui dispositivi registrati.

Essenziale per automatizzare la distribuzione dei certificati client per EAP-TLS su scala. Senza l'integrazione MDM, l'installazione manuale dei certificati su migliaia di dispositivi è operativamente impossibile.

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo utilizzato per automatizzare l'emissione di certificati digitali ai dispositivi di rete. Le piattaforme MDM utilizzano SCEP per richiedere e installare silenziosamente certificati sui dispositivi aziendali registrati senza l'interazione dell'utente.

Il meccanismo standard per il provisioning dei certificati zero touch nelle implementazioni EAP-TLS. Supportato da Microsoft Intune, Jamf e dalla maggior parte delle piattaforme MDM aziendali.

CRL (Certificate Revocation List)

Un elenco di certificati digitali che sono stati revocati dall'Autorità di Certificazione emittente prima della loro data di scadenza prevista. I server RADIUS controllano la CRL per verificare che il certificato di un dispositivo connesso sia ancora valido.

Il meccanismo che consente di bloccare immediatamente l'accesso alla rete a un dispositivo rubato o compromesso revocandone il certificato. I server RADIUS devono essere configurati per controllare frequentemente la CRL, oppure utilizzare OCSP per la convalida in tempo reale.

X.509

Uno standard ITU-T che definisce il formato dei certificati a chiave pubblica. EAP-TLS ed EAP-TTLS utilizzano entrambi certificati X.509 per l'autenticazione del server. EAP-TLS richiede anche certificati X.509 sul dispositivo client.

Il formato di certificato utilizzato in tutte le distribuzioni PKI aziendali. Quando i team IT fanno riferimento ai "certificati digitali" nel contesto di 802.1X, intendono i certificati X.509.

Metodo di autenticazione interna

Il protocollo di autenticazione secondario utilizzato all'interno del tunnel TLS crittografato stabilito da EAP-TTLS. I metodi interni comuni includono PAP (Password Authentication Protocol), CHAP e MS-CHAPv2.

La scelta del metodo di autenticazione interna influisce sulle proprietà di sicurezza di una distribuzione EAP-TTLS. PAP invia la password in testo non crittografato all'interno del tunnel; MS-CHAPv2 utilizza un meccanismo di challenge-response. Il tunnel crittografa tutto il traffico di autenticazione interna.

Esempi pratici

Una catena di vendita al dettaglio nazionale con 400 negozi deve proteggere i propri terminali POS e gli scanner portatili del personale. L'ambiente rientra nell'ambito di applicazione dello standard PCI-DSS 4.0. Tutti i dispositivi sono registrati in Microsoft Intune. Quale protocollo dovrebbero implementare e quali sono le fasi chiave di configurazione?

Implementare EAP-TLS. Passaggio 1: stabilire una PKI a due livelli con una CA radice offline isolata e una CA emittente online. Passaggio 2: configurare Microsoft Intune con un profilo di certificato SCEP destinato a tutti i dispositivi POS e scanner. Passaggio 3: distribuire un server RADIUS (Microsoft NPS o RADIUS in cloud) e configurarlo per convalidare i certificati client rispetto alla CA interna. Passaggio 4: abilitare il controllo CRL o OCSP sul server RADIUS. Passaggio 5: inviare un profilo WiFi tramite Intune specificando l'SSID, EAP-TLS come metodo di autenticazione, la CA radice attendibile e il nome del server RADIUS previsto. Passaggio 6: testare con un gruppo pilota di 10 dispositivi prima di procedere alla distribuzione in tutti i 400 siti. Passaggio 7: stabilire un processo di monitoraggio della scadenza dei certificati con avvisi a 60, 30 e sette giorni dalla scadenza.

Commento dell'esaminatore: EAP-TLS è la scelta corretta poiché lo standard PCI-DSS 4.0 raccomanda fortemente l'autenticazione reciproca tramite certificati per le reti wireless nell'ambiente dei dati dei titolari di carta. Affidarsi alle password (EAP-TTLS) per i dispositivi POS introduce un rischio inaccettabile di furto di credenziali. L'integrazione MDM tramite SCEP è essenziale - l'installazione manuale dei certificati su 400 siti è operativamente impossibile. Il punto di errore più comune in questo scenario consiste nel dimenticare di imporre la convalida del certificato del server nel profilo WiFi di Intune, il che lascerebbe i dispositivi vulnerabili agli attacchi Evil Twin nonostante l'implementazione di EAP-TLS.

Un grande campus universitario deve fornire un accesso WiFi sicuro a 20.000 studenti che utilizzano un mix di laptop personali, smartphone e tablet (BYOD). Il team IT non può installare certificati sui dispositivi personali. L'università utilizza Microsoft Entra ID per la gestione delle identità. Quale protocollo dovrebbe implementare?

Implementare EAP-TTLS con MS-CHAPv2 come metodo di autenticazione interno, integrato con Microsoft Entra ID tramite RADIUS. Passaggio 1: ottenere un certificato server da una CA pubblica attendibile da tutti i principali sistemi operativi, oppure distribuire una CA interna e distribuire il certificato radice tramite gli strumenti di gestione dei dispositivi dell'università per i dispositivi gestiti. Passaggio 2: configurare il server RADIUS per l'autenticazione rispetto a Microsoft Entra ID utilizzando LDAP o proxy RADIUS. Passaggio 3: creare una guida all'onboarding WiFi per gli studenti specificando l'SSID, EAP-TTLS, MS-CHAPv2 e la CA attendibile. Passaggio 4: applicare policy per password sicure a livello di Microsoft Entra ID e valutare l'abilitazione dell'autenticazione a più fattori per la registrazione iniziale. Passaggio 5: configurare il profilo WiFi per imporre la convalida del certificato del server e specificare la CA attendibile e il nome del server RADIUS.

Commento dell'esaminatore: EAP-TTLS è la scelta pragmatica in questo caso. Gestire una PKI per 20.000 dispositivi personali non gestiti è operativamente impossibile. EAP-TTLS fornisce un tunnel sicuro per le credenziali, proteggendole dall'intercettazione via radio e supportando al contempo diversi sistemi operativi tra cui Windows, macOS, Linux, Android e iOS. Il rischio critico in questo scenario è che gli studenti configurino erroneamente i propri dispositivi saltando la convalida del certificato del server. La pubblicazione di una guida di onboarding chiara con i passaggi di configurazione esatti, e l'uso di un certificato server pubblicamente attendibile, riduce significativamente questo rischio.

Domande di esercitazione

Q1. Stai distribuendo EAP-TLS per una flotta di 5.000 laptop aziendali in 50 sedi d'ufficio. Dopo aver distribuito il profilo WiFi tramite Microsoft Intune, i dispositivi non riescono a connettersi. I log del server RADIUS mostrano "Unknown CA" per ogni tentativo di autenticazione non riuscito. Qual è la causa più probabile e come si risolve?

Suggerimento: Considera la catena di convalida dei certificati sul lato client e cosa deve includere il profilo MDM oltre alla semplice impostazione del metodo EAP.

Visualizza risposta modello

I dispositivi client non sono configurati per considerare attendibile l'Autorità di Certificazione interna che ha emesso il certificato del server RADIUS. Il profilo WiFi MDM deve includere il certificato della CA radice (e gli eventuali certificati CA intermedi) e configurare il supplicant per ritenerli attendibili per la convalida del server. Senza questo, il client rifiuta il certificato del server RADIUS e interrompe l'handshake. Risoluzione: aggiornare il profilo WiFi di Intune per includere il certificato della CA radice attendibile nell'impostazione "Certificato radice per la convalida del server" e ridistribuire il profilo su tutti i dispositivi.

Q2. La tua organizzazione ha distribuito EAP-TTLS per un ambiente BYOD misto. Durante una revisione della sicurezza, il tuo team di penetration testing dimostra di poter catturare le credenziali degli utenti configurando un access point fittizio con un certificato autofirmato. Come puoi rimediare a questa vulnerabilità senza migrare a EAP-TLS?

Suggerimento: Pensa a cosa succede prima dell'autenticazione interna e quale configurazione sul lato client impedisce al tunnel TLS di stabilirsi con un server non attendibile.

Visualizza risposta modello

La vulnerabilità esiste perché i dispositivi client non sono configurati per convalidare il certificato del server RADIUS. Soluzione: aggiornare tutti i profili WiFi (tramite MDM per i dispositivi gestiti e tramite una nuova guida all'onboarding per il BYOD) per imporre la convalida del certificato del server. Specificare la CA attendibile e il nome del server RADIUS previsto nel profilo. I client configurati in questo modo rifiuteranno di stabilire il tunnel TLS con qualsiasi server che non sia in grado di presentare un certificato firmato dalla CA attendibile specificata, eliminando il vettore di attacco dell'access point fittizio.

Q3. Un direttore IT ospedaliero desidera distribuire 802.1X per i propri dispositivi IoT medici (pompe di infusione, monitor dei pazienti, sensori ambientali). Sta valutando EAP-TTLS perché ritiene che la gestione dei certificati sia troppo complessa. Perché questo ragionamento è errato e qual è l'approccio corretto?

Suggerimento: Considera come i dispositivi IoT headless gestiscono le richieste di autenticazione e cosa succede quando un dispositivo non può inserire le credenziali.

Visualizza risposta modello

Il ragionamento è errato per due motivi. Primo, la maggior parte dei dispositivi IoT medicali headless non ha un'interfaccia utente per inserire le credenziali, rendendo operativamente impossibile l'uso di EAP-TTLS con autenticazione interna tramite nome utente/password. Secondo, EAP-TLS è in realtà più semplice per l'IoT nella pratica: i certificati possono essere predisposti durante la configurazione iniziale del dispositivo prima dell'implementazione, e il dispositivo si autentica automaticamente senza interazione dell'utente. L'approccio corretto è EAP-TLS con certificati distribuiti tramite il sistema di gestione dei dispositivi utilizzato in fase di configurazione. Questo soddisfa anche i requisiti HIPAA per l'autenticazione wireless forte negli ambienti sanitari.

Q4. Sei l'architetto di rete per un gruppo alberghiero con 200 proprietà. Devi proteggere la rete Staff WiFi per 3.000 dispositivi gestiti del personale (registrati in Intune) e fornire anche un accesso WiFi sicuro a collaboratori esterni e fornitori terzi che utilizzano i propri laptop. Progetta l'architettura di autenticazione.

Suggerimento: Considera se un singolo SSID con un unico metodo EAP può servire entrambe le popolazioni e quali implicazioni di segmentazione della rete derivano dai due tipi di utenti.

Visualizza risposta modello

Configura due SSID separati con diversi metodi di autenticazione e assegnazioni VLAN. SSID 1 (Staff WiFi): EAP-TLS, certificati distribuiti tramite Intune SCEP, VLAN assegnata al segmento di rete del personale con accesso completo ai sistemi di gestione dell'hotel. SSID 2 (Contractor WiFi): EAP-TTLS con MS-CHAPv2, credenziali convalidate rispetto a una directory separata o a un account collaboratore a tempo limitato in Microsoft Entra ID, VLAN assegnata a un segmento isolato abilitato solo per internet, senza accesso ai sistemi interni. Entrambi gli SSID devono imporre la convalida del certificato del server. Questa architettura offre al personale il massimo livello di sicurezza fornendo al contempo ai collaboratori esterni un metodo di autenticazione pratico, mentre la segmentazione della rete garantisce che una credenziale compromessa di un collaboratore non possa raggiungere i sistemi di gestione interni dell'hotel.

Continua a leggere questa serie

Configuring RADIUS Authentication for Guest and Staff WiFi Networks

Questa guida di riferimento tecnica descrive l'architettura, la configurazione e l'implementazione dell'autenticazione RADIUS per le reti WiFi aziendali per ospiti e personale. Fornisce ai network architect e ai manager IT i protocolli esatti, gli standard di sicurezza e le metodologie di risoluzione dei problemi necessari per creare sistemi di controllo degli accessi wireless sicuri e scalabili.

Passpoint and OpenRoaming: Complete Guide

Questa guida di riferimento tecnico fornisce un'analisi completa dei framework Passpoint (Hotspot 2.0) e WBA OpenRoaming all'interno delle reti WiFi aziendali. Descrive in dettaglio i protocolli di autenticazione sottostanti, i componenti architetturali e le strategie di implementazione necessarie per stabilire una connettività guest sicura e senza attriti. I progettisti di rete e i responsabili IT impareranno a progettare, implementare e risolvere i problemi di questi standard per eliminare le barriere di accesso manuale mantenendo al contempo una sicurezza di livello enterprise.

Come Implementare SCEP per il Secure BYOD e l'Iscrizione di Rete nell'Istruzione Superiore

Questa guida tecnica fornisce ad architetti di rete e responsabili IT un modello indipendente dal fornitore per implementare la registrazione dei certificati basata su SCEP per proteggere le reti dei campus universitari. Descrive in dettaglio come migrare dal protocollo PEAP basato su password a 802.1X EAP-TLS, automatizzare l'onboarding dei dispositivi BYOD e applicare una robusta segmentazione VLAN.