EAP-TLS vs EAP-TTLS : Quel protocole WiFi basé sur les certificats devriez-vous choisir ?

Synthèse

Choisir la bonne méthode EAP pour votre déploiement 802.1X détermine si votre WiFi d'entreprise est véritablement sécurisé ou simplement conforme sur le papier. Le protocole EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), défini dans la RFC 5216, nécessite une authentification mutuelle par certificat : le périphérique client et le serveur RADIUS présentent tous deux des certificats X.509 valides avant que l'accès au réseau ne soit accordé. À aucun moment des mots de passe ne sont échangés. Le protocole EAP-TTLS (Tunneled Transport Layer Security), défini dans la RFC 5281, ne nécessite qu'un certificat côté serveur pour établir un tunnel TLS chiffré, à l'intérieur duquel le client s'authentifie à l'aide de ses identifiants d'annuaire existants.

Pour les directeurs techniques et les architectes réseau qui gèrent des infrastructures dans des chaînes de magasins, des établissements hôteliers et des organisations du secteur public, cette décision se résume à une question : gérez-vous les périphériques ? Si vous contrôlez le parc de périphériques via un MDM, EAP-TLS est le choix définitif. Si vous prenez en charge un environnement BYOD diversifié ou si vous ne disposez pas d'une infrastructure de clés publiques (PKI) robuste, EAP-TTLS offre une alternative pragmatique et hautement sécurisée. Purple prend en charge ces deux parcours d'authentification pour le Staff WiFi sur plus de 80 000 sites actifs.

Analyse Technique Approfondie

Architecture d'EAP-TLS

EAP-TLS fonctionne sur un modèle d'authentification mutuelle au sein du cadre de contrôle d'accès basé sur les ports IEEE 802.1X. Chaque échange d'authentification implique trois composants clés : le supplicant (périphérique client), l'authentificateur (point d'accès sans fil) et le serveur d'authentification (serveur RADIUS). Le point d'accès ne prend pas lui-même la décision d'authentification. Il agit comme un relais transparent, encapsulant les messages EAP dans des paquets RADIUS et les transmettant au serveur d'authentification. La poignée de main (handshake) EAP-TLS se déroule comme suit. Le point d'accès envoie une requête EAP-Request/Identity à l'appareil qui se connecte. L'appareil répond avec son identité. Le serveur RADIUS lance la poignée de main TLS avec un message EAP-TLS/Start. Le client envoie un ClientHello, indiquant les suites de chiffrement TLS qu'il prend en charge. Le serveur RADIUS répond par un ServerHello, son certificat de serveur X.509 et une demande de certificat. Le client valide le certificat du serveur par rapport à son magasin d'autorités de certification (CA) racines de confiance. Si la validation échoue, la poignée de main se termine - offrant ainsi une protection contre les points d'accès malveillants. Le client présente ensuite son propre certificat X.509. Le serveur RADIUS valide le certificat du client, en vérifiant la chaîne de signatures jusqu'à la CA racine de confiance, en s'assurant que le certificat n'a pas expiré et en consultant la liste de révocation de certificats (CRL) ou en interrogeant l'OCSP. Le tunnel TLS n'est établi et l'accès au réseau n'est accordé que lorsque les deux parties sont satisfaites.

Puisqu'aucun mot de passe n'est échangé, EAP-TLS est protégé contre les attaques par dictionnaire hors ligne, le bourrage d'identifiants (credential stuffing) et le phishing. C'est la seule méthode EAP qui répond aux exigences de la norme WPA3-Enterprise 192-bit (Suite B), et elle est imposée ou fortement recommandée par la norme PCI-DSS 4.0 pour les environnements de données de titulaires de cartes et par la norme NIST SP 800-120 pour les déploiements sans fil de haute sécurité.

EAP-TLS nécessite une PKI. Vous avez besoin d'au moins une CA racine hors ligne et d'une CA émettrice en ligne. La CA racine doit être isolée physiquement (air-gapped), car sa clé privée est l'ancêtre de confiance maître pour toute votre hiérarchie de certificats. La CA émettrice gère l'émission quotidienne des certificats et publie les CRL. Les certificats clients sont délivrés à des appareils individuels, et non à des utilisateurs - il s'agit d'un modèle d'identité d'appareil. Cette distinction est essentielle pour les appareils IoT, les terminaux partagés et les systèmes sans écran (headless).

Structure de l'EAP-TTLS

L'EAP-TTLS a été conçu pour fournir une sécurité 802.1X robuste sans la charge opérationnelle liée au déploiement de certificats sur chaque appareil client. Il fonctionne en deux phases. Dans la première phase, le serveur RADIUS présente son certificat et établit un tunnel TLS sécurisé. Seul le serveur a besoin d'un certificat. Dans la deuxième phase, le client est autorisé au sein de ce tunnel chiffré à l'aide d'une méthode d'authentification interne. Les méthodes internes courantes incluent PAP (Password Authentication Protocol), CHAP et MS-CHAPv2. Le client envoie son nom d'utilisateur et son mot de passe, mais comme cet échange se produit au sein du tunnel TLS, les identifiants sont chiffrés en transit et ne sont jamais exposés sur le réseau WiFi.

EAP-TTLS offre une excellente compatibilité multiplateforme sur macOS, Linux, Android et iOS. La seule réserve concerne Windows : le demandeur (supplicant) intégré à Windows ne prend pas en charge nativement EAP-TTLS pour le 802.1X sans fil standard. Les environnements comptant un grand nombre d'appareils Windows peuvent nécessiter un demandeur tiers, ce qui augmente la complexité opérationnelle. Pour les environnements principalement axés sur Windows, PEAP avec MS-CHAPv2 est souvent le choix le plus pragmatique.

La plus grande limitation d'EAP-TTLS est qu'il n'élimine pas les risques inhérents aux mots de passe. Si un utilisateur choisit un mot de passe faible, il reste vulnérable aux attaques par force brute hors ligne. Si l'authentification interne utilise PAP, le mot de passe est envoyé en texte clair à l'intérieur du tunnel - ce qui est acceptable si vous faites confiance à votre infrastructure RADIUS, mais cela reste un modèle de confiance essentiel à comprendre.

Comparaison Côte à Côte

Guide d'Implémentation

Déploiement d'EAP-TLS pour les Parcs d'Appareils Gérés

Le déploiement d'EAP-TLS nécessite une PKI fonctionnelle et une plateforme MDM. L'installation manuelle des certificats n'est pas viable à l'échelle de l'entreprise. Vous devez intégrer votre PKI avec votre MDM via SCEP (Simple Certificate Enrolment Protocol) ou EST (Enrolment over Secure Transport). Lorsqu'un appareil d'entreprise est enregistré, il demande et reçoit automatiquement son certificat sans intervention de l'utilisateur.

Pour la gestion des identités, Purple agit comme un fournisseur d'identité gratuit pour des services tels que OpenRoaming sous la licence Connect, facilitant l'itinérance sécurisée à travers différents sites en utilisant des frameworks sous-jacents de certificats et d'identités.

Du côté RADIUS, configurez votre serveur pour valider les certificats clients par rapport à votre autorité de certification (CA) interne et vérifiez les listes de révocation de certificats (CRL) ou utilisez OCSP pour la vérification de révocation en temps réel. Les plateformes RADIUS supportées incluent FreeRADIUS, Microsoft NPS et Cisco ISE. L'overlay cloud de Purple s'intègre avec le matériel Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet.

Déploiement d'EAP-TTLS pour les Environnements Mixtes

EAP-TTLS est le choix optimal pour les environnements comportant des appareils non gérés. Il vous suffit de déployer un certificat de confiance sur votre serveur RADIUS. Assurez-vous que votre serveur RADIUS s'intègre directement avec votre service d'annuaire - Microsoft Entra ID, Okta ou Google Workspace - pour valider les identifiants d'authentification interne. Configurez les profils WiFi déployés par votre MDM pour imposer la validation du certificat serveur par rapport à votre autorité de certification (CA) de confiance spécifique. Sans cette étape, le tunnel TLS ne fournit aucune protection contre les points d'accès malveillants.

Bonnes pratiques

Imposer la validation du certificat du serveur sur chaque client

L'étape de configuration la plus critique pour EAP-TLS et EAP-TTLS consiste à imposer la validation du certificat du serveur sur les appareils clients. Si un appareil ne valide pas le certificat du serveur RADIUS par rapport à une autorité de certification (CA) de confiance spécifique, il se connectera à n'importe quel serveur présentant n'importe quel certificat - y compris un point d'accès malveillant. Spécifiez toujours la CA de confiance et le nom de serveur attendu dans vos profils WiFi déployés par MDM. Ce simple contrôle de configuration est l'amélioration de sécurité la plus efficace que vous puissiez implémenter aujourd'hui.

Automatiser la gestion du cycle de vie des certificats

Les certificats expirent. Si vous ne disposez pas d'un processus de renouvellement automatisé, vous ferez face à des échecs d'authentification massifs lorsque les certificats expireront simultanément. Utilisez SCEP ou EST pour automatiser les renouvellements, et configurez des alertes de surveillance bien avant les dates d'expiration. Si un appareil est perdu ou qu'un employé s'en va, révoquez immédiatement le certificat. Configurez votre serveur RADIUS pour vérifier les CRL ou utilisez OCSP pour une validation en temps réel.

Segmenter votre réseau par méthode d'authentification

Dans les environnements vastes ou distribués, envisagez d'exécuter les deux protocoles sur des SSIDs distincts. Les appareils gérés par l'entreprise s'authentifient via EAP-TLS sur un SSID WiFi dédié au personnel. Les sous-traitants et les appareils BYOD s'authentifient via EAP-TTLS sur un SSID séparé avec une segmentation VLAN appropriée. Ce modèle est courant dans les groupes hôteliers comme Premier Inn et Whitbread, où les appareils du personnel sont gérés et reçoivent des certificats, tandis que l'infrastructure des invités utilise un parcours d'authentification distinct. Pour plus de détails sur l'architecture SSID, consultez notre guide Trois SSIDs pour régner sur tous : la conception WiFi pour les invités, le personnel et l'IoT.

Synchroniser l'heure sur l'ensemble de l'infrastructure

La validation des certificats repose sur une heure système précise. Un décalage de l'horloge sur les appareils clients ou les serveurs RADIUS génère des erreurs de certificat « pas encore valide » ou « expiré » qui sont difficiles à diagnostiquer. Assurez-vous que tous les composants de l'infrastructure sont synchronisés avec des serveurs NTP fiables.

Dépannage et atténuation des risques

Erreurs de CA inconnue

Si les journaux RADIUS indiquent « CA inconnue », l'appareil client ne fait pas confiance à la CA qui a émis le certificat du serveur RADIUS. Vérifiez que votre profil MDM inclut le certificat de la CA racine et que le suppliant est configuré pour lui faire confiance. À la suite d'une rotation de CA ou d'un renouvellement de certificat, renvoyez le bundle de CA mis à jour vers tous les appareils.

Incompatibilité de méthode EAP

Si les appareils se connectent au point d'accès mais que l'authentification échoue, vérifiez que la méthode EAP configurée sur le client correspond à la méthode acceptée par le serveur RADIUS. Un profil d'appareil configuré pour EAP-TLS échouera sur un serveur RADIUS configuré uniquement pour PEAP.

Échecs massifs dus à des certificats expirés

Si un grand nombre d'appareils ne parviennent pas à s'authentifier simultanément, vérifiez d'abord les dates d'expiration des certificats. C'est la cause la plus fréquente d'échecs de masse du protocole 802.1X dans les déploiements EAP-TLS. Mettez en place un système de surveillance qui envoie des alertes 60 jours, 30 jours et sept jours avant l'expiration.

Mauvaise configuration du client RADIUS

Chaque point d'accès ou contrôleur sans fil doit être défini comme un client RADIUS avec l'adresse IP correcte et le secret partagé. Les non-correspondances entraînent des délais d'attente d'authentification qui sont souvent attribués à tort à la méthode EAP. Activez la journalisation détaillée RADIUS dès le premier jour. Pour obtenir d'autres conseils sur le dépannage de votre réseau WiFi, consultez notre guide Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures.

-

Conformité et alignement réglementaire

Pour les RSSI et les architectes réseau, il est essentiel de comprendre le paysage réglementaire au moment de choisir entre EAP-TLS et EAP-TTLS. Le choix de la méthode EAP a un impact direct sur votre posture de conformité par rapport à plusieurs cadres clés.

PCI-DSS 4.0 (Payment Card Industry Data Security Standard) exige une authentification cryptographique forte pour les réseaux sans fil dans les environnements de données de titulaires de cartes. L'exigence 8.3 impose une authentification multifacteur pour tout accès au CDE, et les réseaux sans fil concernés doivent utiliser des mécanismes d'authentification forts. L'EAP-TLS, avec son authentification mutuelle basée sur des certificats, répond définitivement à cette exigence. L'EAP-TTLS avec MS-CHAPv2 est acceptable si l'authentification interne est correctement sécurisée et si la validation du certificat du serveur est appliquée, mais l'EAP-TLS reste le choix le plus robuste et le plus simple à auditer. HIPAA (Health Insurance Portability and Accountability Act) exige que les entités couvertes mettent en œuvre des garanties techniques pour protéger les informations de santé protégées électroniques (ePHI) transmises sur les réseaux de communication électronique. La règle de sécurité HIPAA n'impose pas de protocoles spécifiques, mais l'exigence de chiffrement et de contrôle d'accès pour les réseaux sans fil transportant des ePHI penche fortement en faveur d'EAP-TLS pour les flottes d'appareils médicaux gérées, et d'EAP-TTLS avec validation forcée des certificats de serveur pour les appareils du personnel.

WPA3-Enterprise 192 bits (également connu sous le nom de mode Suite B ou CNSA) est le niveau de sécurité le plus élevé de la certification WPA3 de la Wi-Fi Alliance. Il impose EAP-TLS comme seule méthode d'authentification autorisée, exige TLS 1.2 ou supérieur avec des suites de chiffrement spécifiques (ECDHE avec P-384, AES-256-GCM), et requiert des certificats ECDSA ou RSA-3072. Les organisations qui déploient WPA3-Enterprise 192 bits pour des applications gouvernementales, de défense ou d'infrastructures critiques doivent impérativement utiliser EAP-TLS.ISO/IEC 27001 n'impose pas de protocoles spécifiques, mais exige que les organisations mettent en œuvre des contrôles d'accès appropriés pour les ressources réseau. Un déploiement 802.1X avec EAP-TLS ou EAP-TTLS (avec validation obligatoire du certificat du serveur) répond aux exigences de contrôle d'accès réseau de l'Annexe A.9.1 et A.13.1.

ROI et impact commercial

La migration vers EAP-TLS nécessite un investissement initial dans l'intégration PKI et MDM, mais elle élimine les coûts opérationnels liés à la réinitialisation des mots de passe et le risque financier de failles réseau dues à des identifiants compromis. Pour une chaîne de vente au détail de 400 magasins, un seul mot de passe compromis sur un réseau PSK partagé peut mettre en péril l'ensemble du parc. EAP-TLS élimine complètement ce vecteur d'attaque.

Pour les environnements multi-locataires et les hubs de transport, l'authentification sécurisée garantit que seuls les utilisateurs autorisés accèdent à la bande passante du réseau, optimisant ainsi l'utilisation de l'infrastructure. L'attribution dynamique de VLAN via les attributs de certificat RADIUS permet une segmentation réseau appliquée par cryptographie, garantissant que les appareils sont placés sur le bon segment de réseau en fonction des propriétés du certificat plutôt que de s'appuyer sur la sélection du SSID ou le filtrage d'adresses MAC.

La plateforme d'analyse WiFi Analytics de Purple s'intègre aux deux voies d'authentification, offrant une visibilité sur le nombre d'appareils, la durée des sessions et l'utilisation du réseau sur l'ensemble de votre parc. Pour obtenir des conseils de déploiement spécifiques à votre secteur, explorez nos ressources pour l'hôtellerie Hospitality, le commerce de détail Retail, la santé Healthcare, et les transports Transport.