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

Qu'est-ce que l'authentification PEAP ? Comment PEAP sécurise votre WiFi. Une note d'information Purple Enterprise WiFi Intelligence. Bienvenue. Si vous êtes responsable de la sécurité réseau d'un groupe hôtelier, d'un réseau de points de vente, d'un stade ou d'une organisation du secteur public, cette note d'information vous est destinée. Au cours des dix prochaines minutes, nous allons aborder l'authentification PEAP - ce qu'elle est concrètement, comment elle fonctionne sous le capot, où elle s'intègre dans votre architecture de sécurité, et surtout, quand elle représente le bon choix par rapport aux situations où vous devriez envisager une solution plus robuste. Entrons dans le vif du sujet. Première section : Contexte et pourquoi cela est crucial aujourd'hui. La plupart des déploiements WiFi d'entreprise actuels reposent encore sur l'un des deux modèles d'authentification. Vous utilisez soit une clé pré-partagée - un mot de passe unique partagé au sein de l'organisation - soit la norme 802.1X, qui est le standard IEEE pour le contrôle d'accès réseau basé sur les ports. PEAP se situe résolument dans le camp du 802.1X, et il s'agit de loin de la méthode EAP la plus largement déployée dans les environnements d'entreprise et institutionnels à l'échelle mondiale. La raison pour laquelle PEAP est devenu si dominant est simple : il a résolu un véritable problème opérationnel. Avant PEAP, le déploiement d'une authentification WiFi basée sur des certificats impliquait de distribuer des certificats clients à chaque appareil - chaque ordinateur portable, chaque téléphone, chaque tablette. Pour une organisation de cinq cents employés avec une politique BYOD, il s'agissait d'un casse-tête de déploiement PKI pour lequel la plupart des équipes informatiques n'avaient tout simplement ni le budget ni le temps. PEAP a proposé une voie intermédiaire : une authentification forte côté serveur via TLS, avec des identifiants par nom d'utilisateur et mot de passe côté client. Aucun certificat client n'est requis. Ce compromis a fait de PEAP le standard de facto pour l'authentification WiFi d'entreprise tout au long des 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 section : 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 suppliant - c'est-à-dire 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 suppliant tente de se connecter, l'authentificateur n'accorde pas immédiatement l'accès. À la place, il lance un échange EAP sur le réseau local - il s'agit d'EAPOL, EAP over LAN. L'authentificateur transmet cette demande 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 approuvés. 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 phase deux 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é, 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 l'accès au réseau est accordé au client. 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 WiFi ne peut pas voir les identifiants en transit. C'est la proposition de valeur fondamentale de PEAP. Maintenant, où PEAP-MSCHAPv2 fait-il défaut ? Il existe deux problèmes importants que tout architecte soucieux de la sécurité doit comprendre. Premièrement : la validation du certificat du serveur. 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 autorité de certification (CA) - un attaquant peut installer un point d'accès malveillant, présenter un faux certificat et intercepter la liaison MSCHAPv2. Des outils comme hostapd-wpe ont rendu cette attaque extrêmement accessible. L'atténuation réside dans une configuration rigoureuse du demandeur : imposer la validation du certificat du serveur, épingler la CA attendue et spécifier le nom commun du serveur. Ceci 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 de défi-réponse MSCHAPv2 peuvent être piraté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 mot de passe affecte donc directement votre 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. Le compromis réside dans la complexité opérationnelle : vous avez besoin d'une PKI, vous devez émettre et gérer les 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 tous les autres, PEAP-MSCHAPv2 avec une configuration rigoureuse reste un choix défendable et pratique. Section trois : 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 distinguent un déploiement PEAP sécurisé d'un déploiement vulnérable. Numéro un : imposez la validation du certificat de serveur sur chaque suppliant. C'est l'élément de configuration le plus crucial. Sous Windows, il s'agit de la case à cocher "Valider le certificat du serveur" dans le profil de réseau sans fil. Sous iOS et Android, il s'agit du champ de certificat de l'autorité de certification (CA) dans la configuration EAP. Si cela n'est pas configuré, votre déploiement PEAP est vulnérable aux attaques de type rogue AP, quel que soit le niveau de configuration du reste. Numéro deux : déployez via un MDM ou une GPO, et non par configuration manuelle. La configuration manuelle par les utilisateurs finaux n'est pas fiable. Les utilisateurs passeront outre les avertissements de certificat. Ils configureront mal le champ CA. Diffusez vos profils sans fil via Microsoft Intune, Jamf ou une stratégie de groupe (GPO). Cela garantit une configuration homogène et conforme aux politiques sur l'ensemble de votre parc. Numéro trois : utilisez au minimum TLS 1.2 sur votre serveur RADIUS. Désactivez TLS 1.0 et 1.1. La plupart des implémentations RADIUS modernes le prennent en charge, mais il convient de le vérifier, en particulier sur les déploiements sur site plus anciens. Numéro quatre : intégrez-le à votre fournisseur d'identité. PEAP-MSCHAPv2 s'authentifie auprès d'un magasin d'identifiants. Ce magasin doit être votre fournisseur d'identité faisant autorité - Active Directory, Azure AD via l'extension NPS, ou un service RADIUS cloud avec intégration LDAP. Ainsi, lorsqu'un employé s'en va, la désactivation de son compte révoque immédiatement son accès au WiFi. Aucun secret partagé à renouveler, pas de déprovisionnement manuel. Numéro cinq : traitez votre réseau invités séparément. PEAP est une méthode d'authentification d'entreprise. Pour le WiFi invités - où vous accueillez des visiteurs, des clients ou des participants à des événements - vous devez adopter une approche différente. Les plateformes comme Purple fournissent une couche WiFi invités 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és. Conservez votre SSID d'entreprise sur du 802.1X avec PEAP, et votre SSID invités sur un réseau distinct 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. Le moment venu, chaque client ayant enregistré ce certificat échouera à s'authentifier jusqu'à ce que le nouveau certificat soit distribué. Intégrez le renouvellement des certificats dans votre calendrier opérationnel - au moins 90 jours avant l'expiration - et testez le processus de rotation dans un environnement de pré-production avant de le déployer en production. Les modes de défaillance les plus courants que je rencontre sur le terrain sont : l'absence de validation stricte des certificats, entraînant une vulnérabilité aux rogue AP ; l'expiration sans avertissement des certificats du serveur RADIUS, provoquant des pannes d'authentification généralisées ; et l'exposition de l'authentification interne MSCHAPv2 parce que le serveur RADIUS est accessible depuis le mauvais segment de réseau. Ces trois problèmes peuvent être évités grâce à une planification adéquate. Section quatre : 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 tels que Cisco ISE, Aruba ClearPass ou JumpCloud RADIUS peuvent s'intégrer directement avec Azure AD ou Okta. Le PEAP est-il conforme à la norme PCI-DSS ? Le PEAP-MSCHAPv2 peut être utilisé dans des environnements PCI-DSS, mais vous devez vous assurer que la validation du certificat du serveur est appliqué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 - passez en revue les exigences applicables avec votre QSA. Dois-je migrer de PEAP vers EAP-TLS ? Si vous disposez d'un déploiement MDM mature et de la capacité opérationnelle nécessaire pour 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 existant ou une couverture MDM limitée, le 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 ? Le WPA3-Enterprise impose un mode de sécurité 192 bits pour les environnements de haute sécurité, mais il prend toujours en charge les méthodes EAP, y compris le PEAP. Le WPA3 améliore le chiffrement radio mais ne modifie pas l'échange d'authentification EAP lui-même. Cinquième section : Résumé et prochaines étapes. En résumé : le PEAP est un protocole d'authentification en deux phases qui enveloppe les 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 fournissant une authentification de serveur forte. Sa vulnérabilité principale réside dans les attaques par point d'accès malveillant, facilitées par des suppliants 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, au épinglage de certificat (CA pinning) et à la validation du nom du serveur. Pour la plupart des déploiements WiFi d'entreprise - bureaux d'entreprise, réseaux d'arrière-guichet d'hôtels, réseaux de personnel de vente au détail - le PEAP-MSCHAPv2 doté d'une configuration adéquate est un choix judicieux et justifiable. Pour les environnements de haute sécurité, les secteurs réglementés ou les organisations disposant d'une infrastructure PKI mature, EAP-TLS offre une sécurité nettement plus forte et devrait constituer l'architecture cible. Si vous exploitez également un WiFi invité parallèlement à votre réseau d'entreprise - ce qui est le cas pour la plupart d'entre vous - rappelez-vous que le PEAP n'est pas l'outil adapté à l'intégration des invités. Tournez-vous vers des plateformes comme Purple, qui fournissent une authentification WiFi invité dédiée avec des fonctionnalités d'analyse, de capture de données et d'intégration marketing, garantissant que vos flux de trafic invité et d'entreprise restent correctement séparés et que votre conformité est préservée. Pour aller plus loin, consultez les guides de Purple sur l'architecture des serveurs RADIUS et l'authentification WiFi d'entreprise. Les liens figurent dans les notes de l'émission. Merci pour votre écoute. C'était un briefing d'information sur le WiFi d'entreprise par Purple.