Qu'est-ce que l'authentification PEAP ? Comment le PEAP sécurise votre WiFi

Qu'est-ce que l'authentification PEAP ? Comment le PEAP sécurise votre WiFi. Un point d'information Purple sur l'intelligence WiFi d'entreprise. Bienvenue. Si vous êtes responsable de la sécurité réseau d'un groupe hôtelier, d'un parc de magasins, d'un stade ou d'une organisation du secteur public, ce point d'information est pour vous. Au cours des dix prochaines minutes, nous allons aborder l'authentification PEAP : ce qu'elle est réellement, son fonctionnement interne, sa place dans votre architecture de sécurité et, surtout, quand elle constitue le bon choix et quand vous devriez envisager une solution plus robuste. C'est parti. Première partie : Contexte et importance actuelle. La plupart des déploiements WiFi d'entreprise reposent aujourd'hui sur l'un des deux modèles d'authentification suivants. Soit vous disposez d'une clé pré-partagée (un mot de passe unique partagé au sein de l'organisation), soit vous utilisez le 802.1X, qui est la norme IEEE pour le contrôle d'accès réseau basé sur les ports. Le PEAP s'inscrit résolument dans la catégorie 802.1X, et c'est de loin la méthode EAP la plus largement déployée dans les environnements d'entreprise et institutionnels à l'échelle mondiale. La raison pour laquelle le PEAP est devenu si dominant est simple : il a résolu un véritable problème opérationnel. Avant le PEAP, le déploiement d'une authentification WiFi basée sur des certificats impliquait d'émettre des certificats clients pour chaque appareil (chaque ordinateur portable, chaque téléphone, chaque tablette). Pour une organisation de cents employés avec une politique BYOD, c'est un casse-tête de déploiement de PKI pour lequel la plupart des équipes informatiques n'avaient tout simplement ni le budget ni le temps. Le PEAP a offert une voie intermédiaire : une authentification robuste côté serveur via TLS, avec des identifiants de type nom d'utilisateur et mot de passe côté client. Aucun certificat client n'est requis. Ce compromis a fait du PEAP la norme de facto pour l'authentification WiFi d'entreprise dans les années 2000 et 2010, et il reste extrêmement courant aujourd'hui. Comprendre son architecture — et ses limites — est essentiel pour quiconque prend des décisions d'infrastructure en 2024 et au-delà. Deuxième partie : Analyse technique approfondie. Voyons en détail ce qui se passe exactement lorsqu'un appareil s'authentifie via PEAP. Le processus comporte deux phases distinctes, et il est essentiel de comprendre les deux. Les trois acteurs de cet échange sont : le supplicant (l'appareil client, qu'il s'agisse d'un ordinateur portable, d'un smartphone ou d'un terminal IoT) ; l'authentificateur (généralement le point d'accès sans fil ou le contrôleur LAN sans fil) ; et le serveur d'authentification (presque toujours un serveur RADIUS, tel que Microsoft NPS, FreeRADIUS ou un service RADIUS hébergé dans le cloud). La première phase est l'établissement du tunnel TLS. Lorsque le supplicant tente de se connecter, l'authentificateur n'accorde pas l'accès immédiatement. Au lieu de cela, il lance un échange EAP sur le réseau local (il s'agit d'EAPOL, EAP over LAN). L'authentificateur transmet cet échange au serveur RADIUS, qui présente son certificat TLS côté serveur au client. Le client valide ce certificat par rapport à son magasin de certificats de confiance. Si la validation réussit, un tunnel TLS est établi entre le client et le serveur RADIUS. Ce tunnel est chiffré (généralement en TLS 1.2 ou 1.3 dans les déploiements modernes). La deuxième phase est l'authentification interne. À l'intérieur de ce tunnel chiffré, les identifiants réels sont échangés. Dans le déploiement le plus courant (PEAP-MSCHAPv2), le client envoie un nom d'utilisateur et un mot de passe à l'aide du protocole Microsoft Challenge Handshake Authentication Protocol version 2. Le serveur RADIUS valide ces identifiants par rapport à son référentiel d'identités, qui peut être Active Directory, LDAP ou un fournisseur d'identité cloud. Si les identifiants sont valides, le serveur RADIUS renvoie un message Access-Accept via l'authentificateur, et le client se voit accorder l'accès au réseau. La propriété de sécurité clé ici est que l'échange MSCHAPv2 se produit à l'intérieur du tunnel TLS. Un attaquant surveillant passivement le canal sans fil ne peut pas voir les identifiants en transit. C'est la proposition de valeur fondamentale du PEAP. Maintenant, quelles sont les limites de PEAP-MSCHAPv2 ? Il existe deux problèmes importants que tout architecte soucieux de la sécurité doit comprendre. Premièrement : la validation du certificat du serveur. Le PEAP exige uniquement que le serveur présente un certificat (il n'exige pas que le client en présente un). Cela crée un vecteur d'attaque bien documenté. Si un appareil client est mal configuré pour accepter n'importe quel certificat (ou pour accepter des certificats de n'importe quelle AC), un attaquant peut mettre en place un point d'accès malveillant, présenter un certificat frauduleux et intercepter la liaison MSCHAPv2. Des outils comme hostapd-wpe ont rendu cette attaque extrêmement accessible. La parade consiste en une configuration rigoureuse du supplicant : imposer la validation du certificat du serveur, épingler l'AC attendue et spécifier le nom commun (CN) du serveur. C'est non négociable dans tout déploiement sérieux. Deuxièmement : MSCHAPv2 est un protocole ancien présentant des faiblesses connues. Les recherches menées en 2012 par Moxie Marlinspike ont démontré que les paires défi-réponse MSCHAPv2 peuvent être déchiffrées hors ligne avec une puissance de calcul suffisante. Si un attaquant parvient à capturer l'échange d'authentification interne (par exemple via l'attaque par point d'accès malveillant décrite ci-dessus), il peut tenter de récupérer le mot de passe en clair hors ligne. La force de votre politique de mots de passe affecte donc directement votre niveau d'exposition. Des mots de passe longs, complexes et générés de manière aléatoire réduisent considérablement ce risque. Comparez cela à EAP-TLS, où le serveur et le client présentent tous deux des certificats. Il n'y a pas de mots de passe à voler. La surface d'attaque est considérablement réduite. La contrepartie est la complexité opérationnelle : vous avez besoin d'une PKI, vous devez émettre et gérer des certificats clients, et vous devez disposer d'un mécanisme pour les distribuer à chaque appareil. Pour les organisations disposant d'un déploiement MDM mature et d'une PKI bien gérée, EAP-TLS est la référence absolue. Pour toutes les autres, PEAP-MSCHAPv2 avec une configuration rigoureuse reste un choix défendable et pratique. Troisième partie : Recommandations de mise en œuvre et pièges à éviter. Laissez-moi vous donner des conseils pratiques de déploiement. Ce sont ces éléments qui séparent un déploiement PEAP sécurisé d'un déploiement vulnérable. Numéro un : imposez la validation du certificat du serveur sur chaque supplicant. C'est l'élément de configuration le plus important. Sous Windows, il s'agit de la case à cocher « Valider le certificat du serveur » dans le profil du réseau sans fil. Sous iOS et Android, il s'agit du champ du certificat de l'AC dans la configuration EAP. Si cela n'est pas configuré, votre déploiement PEAP est vulnérable aux attaques par point d'accès malveillant, quel que soit le niveau de configuration du reste. Numéro deux : déployez via MDM ou GPO, pas par configuration manuelle. La configuration manuelle par les utilisateurs finaux n'est pas fiable. Les utilisateurs cliqueront pour passer outre les avertissements de certificat. Ils configureront mal le champ de l'AC. Poussez vos profils sans fil via Microsoft Intune, Jamf ou les stratégies de groupe (GPO). Cela garantit une configuration cohérente et conforme aux politiques de sécurité des supplicants sur l'ensemble de votre parc. Numéro trois : utilisez TLS 1.2 au minimum sur votre serveur RADIUS. Désactivez TLS 1.0 et 1.1. La plupart des implémentations RADIUS modernes le prennent en charge, mais cela vaut la peine de le vérifier, en particulier sur les déploiements sur site plus anciens. Numéro quatre : intégrez votre fournisseur d'identité. PEAP-MSCHAPv2 s'authentifie par rapport à un référentiel d'identifiants. Ce référentiel doit être votre fournisseur d'identité de référence : Active Directory, Azure AD via l'extension NPS, ou un service RADIUS cloud avec intégration LDAP. Cela signifie que lorsqu'un employé s'en va, la désactivation de son compte révoque immédiatement son accès WiFi. Pas de secrets partagés à renouveler, pas de déprovisionnement manuel. Numéro cinq : gérez votre réseau invité séparément. Le PEAP est une méthode d'authentification d'entreprise. Pour le WiFi invité — où vous accueillez des visiteurs, des clients ou des participants à des événements — vous avez besoin d'une approche différente. Les plateformes comme Purple fournissent une couche WiFi invité dédiée qui gère l'authentification par Captive Portal, la capture de données et les analyses sans nécessiter d'infrastructure RADIUS sur l'SSID invité. Conservez votre SSID d'entreprise sur du 802.1X avec PEAP, et votre SSID invité sur un réseau séparé et isolé avec un parcours d'accès adapté. Numéro six : planifiez le renouvellement des certificats. Le certificat de votre serveur RADIUS va expirer. Lorsque cela se produira, tous les clients ayant épinglé ce certificat ne parviendront plus à s'authentifier tant que le nouveau certificat n'aura pas été distribué. Intégrez le renouvellement des certificats dans votre calendrier opérationnel (au moins 90 jours avant l'expiration) et testez le processus de renouvellement dans un environnement de pré-production avant de le déployer en production. Les modes de défaillance les plus courants que je constate sur le terrain sont : la validation des certificats non imposée, entraînant une vulnérabilité aux points d'accès malveillants ; des certificats de serveur RADIUS qui expirent sans avertissement, provoquant des pannes d'authentification généralisées ; et l'authentification interne MSCHAPv2 exposée parce que le serveur RADIUS est accessible depuis un segment réseau inapproprié. Ces trois problèmes peuvent être évités grâce à une planification adéquate. Quatrième partie : Questions-réponses rapides. Le PEAP peut-il fonctionner avec des fournisseurs d'identité cloud comme Azure AD ? Oui. L'extension NPS de Microsoft pour Azure AD MFA vous permet de relayer l'authentification PEAP via Azure AD, activant ainsi l'authentification multifacteur sur votre WiFi. Alternativement, des services RADIUS cloud comme Cisco ISE, Aruba ClearPass ou JumpCloud RADIUS peuvent s'intégrer directement à Azure AD ou Okta. Le PEAP est-il conforme à la norme PCI DSS ? PEAP-MSCHAPv2 peut être utilisé dans des environnements PCI DSS, mais vous devez vous assurer que la validation du certificat du serveur est imposée, que TLS 1.2 ou supérieur est utilisé et que le serveur RADIUS est correctement segmenté. La norme PCI DSS 4.0 renforce les exigences relatives aux contrôles d'accès réseau — examinez les exigences applicables avec votre QSA. Dois-je migrer du PEAP vers EAP-TLS ? Si vous disposez d'un déploiement MDM mature et de la capacité opérationnelle de gérer une PKI, oui — EAP-TLS est le choix le plus robuste. Si vous gérez un parc mixte comprenant des appareils personnels, du matériel hérité ou une couverture MDM limitée, PEAP-MSCHAPv2 avec une configuration rigoureuse reste approprié. Il s'agit d'une décision basée sur le risque, et non d'un choix binaire. Qu'en est-il de WPA3-Enterprise ? WPA3-Enterprise impose un mode de sécurité 192 bits pour les environnements hautement sécurisés, mais prend toujours en charge les méthodes EAP, y compris le PEAP. Le WPA3 améliore le chiffrement des communications radio mais ne modifie pas l'échange d'authentification EAP lui-même. Cinquième partie : Résumé et prochaines étapes. En résumé : le PEAP est un protocole d'authentification en deux phases qui enveloppe des identifiants internes — généralement MSCHAPv2 — dans un tunnel TLS. C'est la méthode EAP 802.1X la plus largement déployée car elle élimine le besoin de certificats clients tout en offrant une authentification robuste du serveur. Sa principale vulnérabilité réside dans les attaques par point d'accès malveillant, rendues possibles par des supplicants mal configurés qui ne valident pas le certificat du serveur. Atténuez ce risque grâce à des profils sans fil imposés par MDM, à l'épinglage de l'AC et à la validation du nom du serveur. Pour la plupart des déploiements WiFi d'entreprise — bureaux d'entreprise, réseaux administratifs d'hôtels, réseaux du personnel de vente au détail — PEAP-MSCHAPv2 avec une configuration appropriée est un choix judicieux et défendable. Pour les environnements hautement sécurisés, les secteurs réglementés ou les organisations disposant d'une infrastructure PKI mature, EAP-TLS offre une sécurité nettement supérieure et devrait être l'architecture cible. Si vous exploitez également un WiFi invité parallèlement à votre réseau d'entreprise — ce qui est le cas de la plupart d'entre vous —, n'oubliez pas que le PEAP n'est pas l'outil adapté pour l'accueil des invités. Tournez-vous vers des plateformes comme Purple, qui fournissent une authentification WiFi invité dédiée avec des analyses, de la capture de données et une intégration marketing, permettant de séparer correctement vos trafics invité et d'entreprise tout en préservant votre conformité. Pour aller plus loin, consultez les guides de Purple sur l'architecture des serveurs RADIUS et l'authentification WiFi d'entreprise. Les liens se trouvent dans les notes de l'émission. Merci pour votre écoute. C'était un point d'information Purple sur l'intelligence WiFi d'entreprise.