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 réseau WiFi d'entreprise est véritablement sécurisé ou simplement conforme sur le papier. EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), défini dans la RFC 5216, nécessite une authentification mutuelle par certificat : l'appareil client et le serveur RADIUS doivent tous deux présenter des certificats X.509 valides avant que l'accès au réseau ne soit accordé. À aucun moment les mots de passe ne sont échangés. 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 technologiques 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 appareils ? Si vous contrôlez le parc d'appareils 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 constitue une alternative pragmatique et hautement sécurisée. Purple prend en charge ces deux voies 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 (appareil 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. Le protocole d'établissement de liaison (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 en fournissant son identité. Le serveur RADIUS lance l'établissement de la liaison TLS avec un message EAP-TLS/Start. Le client envoie un message ClientHello, indiquant les suites de chiffrement TLS qu'il prend en charge. Le serveur RADIUS répond avec un message 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 liaison s'arrête - 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 l'hameçonnage. C'est la seule méthode EAP qui répond aux exigences de WPA3-Enterprise 192 bits (Suite B), et elle est obligatoire 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 WiFi hautement sécurisés.

EAP-TLS nécessite une PKI. Vous avez besoin au minimum d'une CA racine hors ligne et d'une CA émettrice en ligne. La CA racine doit être isolée physiquement du réseau (air-gapped), car sa clé privée constitue l'ancre de confiance principale pour l'ensemble de 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.

Structure de EAP-TTLS

EAP-TTLS a été conçu pour offrir 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, l'utilisateur ou l'appareil est autorisé à l'intérieur 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 transmet son nom d'utilisateur et son mot de passe, mais comme cet échange se déroule au sein du tunnel TLS, les identifiants sont chiffrés en transit et ne sont jamais exposés sur le réseau hertzien.

EAP-TTLS offre une excellente prise en charge multiplateforme sur macOS, Linux, Android et iOS. La seule restriction concerne Windows : le demandeur (supplicant) intégré de Windows ne prend pas en charge nativement EAP-TTLS pour le protocole sans fil 802.1X de manière standard. Les environnements comptant un grand nombre d'appareils Windows peuvent nécessiter un demandeur tiers, ce qui accroît la complexité opérationnelle. Pour les environnements principalement axés sur Windows, PEAP avec MS-CHAPv2 s'avère souvent le choix le plus pragmatique.La plus grande limite de 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 clair dans le tunnel - ce qui est acceptable si vous faites confiance à votre infrastructure RADIUS, mais reste un modèle de confiance essentiel à comprendre.

Comparaison Côte à Côte

Guide d'Implémentation

Déploiement de EAP-TLS pour les Parcs Gérés

Le déploiement de 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 à votre MDM en utilisant 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 en tant que fournisseur d'identité gratuit pour des services comme OpenRoaming sous la licence Connect, facilitant l'itinérance sécurisée entre différents sites en utilisant des frameworks de certificats et d'identités sous-jacents.

Du côté du RADIUS, configurez votre serveur pour valider les certificats clients par rapport à votre CA interne et vérifiez les 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. La surcouche 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 de EAP-TTLS pour les Environnements Mixtes

EAP-TTLS est le choix optimal pour les environnements avec des appareils non gérés. Vous devez uniquement déployer un certificat de confiance sur votre serveur RADIUS. Assurez-vous que votre serveur RADIUS s'intègre directement à votre service d'annuaire - Microsoft Entra ID, Okta ou Google Workspace - pour valider les identifiants d'authentification interne. Configurez vos profils WiFi déployés par MDM pour imposer la validation du certificat serveur par rapport à votre CA de confiance spécifique. Sans cette étape, le tunnel TLS n'offre 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 serez confronté à des échecs d'authentification de masse 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 si un employé s'en va, révoquez immédiatement le certificat. Configurez votre serveur RADIUS pour vérifier les listes de révocation de certificats (CRL) ou utilisez le protocole 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 SSID 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 distinct 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 chemin d'authentification distinct. Pour plus de détails sur l'architecture SSID, consultez notre guide Trois SSID pour régner sur tous : le design 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é" 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 d'autorité de certification (CA) inconnue

Si les journaux du serveur RADIUS affichent "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 demandeur est configuré pour lui faire confiance. À la suite d'une rotation de CA ou d'un renouvellement de certificat, renvoyez le package 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 à celle 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 en même temps, vérifiez d'abord les dates d'expiration des certificats. C'est la cause la plus fréquente d'échecs massifs de la norme 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 7 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 et le secret partagé corrects. Les non-correspondances entraînent des dépassements de délai d'authentification qui sont souvent attribués à tort à la méthode EAP. Activez la journalisation RADIUS détaillée dès le premier jour. Pour plus de conseils sur le dépannage WiFi, consultez notre guide Dépannage du WiFi public : résoudre les échecs 'Connecté, pas d'Internet' et les problèmes de redirection vers la page de portail captif .

-

Conformité et alignement réglementaire

Pour les RSSI et les architectes réseau, la compréhension du paysage réglementaire est essentielle pour 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 WiFi concernés doivent utiliser des mécanismes d'authentification forts. EAP-TLS, avec authentification mutuelle basée sur des certificats, répond de manière définitive à cette exigence. 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 EAP-TLS reste le choix le plus robuste et le plus simple pour les audits. HIPAA (Health Insurance Portability and Accountability Act) exige que les entités couvertes mettent en œuvre des mesures de protection techniques pour sécuriser les informations de santé protégées électroniques (ePHI) transmises sur les réseaux de communication électronique. La règle de sécurité HIPAA ne prescrit pas de protocoles spécifiques, mais l'attente en matière de chiffrement et de contrôle d'accès pour les réseaux WiFi transportant des ePHI penche fortement en faveur d'EAP-TLS pour les parcs d'appareils médicaux gérés, et d'EAP-TTLS avec validation obligatoire du certificat serveur pour les appareils du personnel.WPA3-Enterprise 192-bit (é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-bit pour des applications gouvernementales, de défense ou d'infrastructures critiques doivent utiliser EAP-TLS. ISO 27001 n'impose pas de protocoles spécifiques, mais exige des organisations qu'elles 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 de serveur) satisfait 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 de la PKI et du MDM, mais elle élimine les coûts opérationnels liés à la réinitialisation des mots de passe et le risque financier de violation de réseau due à 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, une 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 du réseau renforcé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'en remettre à la sélection de l'SSID ou au filtrage d'adresses MAC.

La plateforme de WiFi Analytics de Purple s'intègre aux deux parcours 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 , le Commerce de détail , la Santé , et les Transports .