RadSec : comment RADIUS sur TLS améliore la sécurité de l'authentification WiFi

RadSec : Comment RADIUS sur TLS améliore la sécurité de l'authentification WiFi Une note d'information Purple Enterprise WiFi Intelligence Durée approximative : 10 minutes --- [INTRODUCTION & CONTEXTE — env. 1 minute] Bienvenue dans la série Purple Enterprise WiFi Intelligence. Je suis votre hôte, et aujourd'hui nous abordons un sujet qui se situe au carrefour de la sécurité réseau et du risque opérationnel : RadSec — formellement défini dans l'RFC 6614 — et pourquoi il devrait figurer sur votre feuille de route d'infrastructure si ce n'est pas déjà le cas. Si vous êtes responsable informatique, architecte réseau ou CTO en charge du WiFi d'entreprise pour un groupe hôtelier, un parc de points de vente, un stade ou un campus du secteur public, cette note d'information vous est destinée. Nous allons expliquer ce qu'est réellement RadSec, pourquoi le protocole RADIUS traditionnel vous expose à des risques, comment déployer RadSec dans un environnement réel et les pièges qui guettent les équipes. Pas de théorie pour le plaisir de la théorie — uniquement les informations dont vous avez besoin pour prendre une décision ce trimestre. C'est parti. --- [ANALYSE TECHNIQUE APPROFONDIE — env. 5 minutes] Commençons donc par le problème. RADIUS — Remote Authentication Dial-In User Service — est le pilier de l'authentification WiFi d'entreprise depuis les années 1990. Lorsqu'un utilisateur ou un appareil se connecte à votre WiFi d'entreprise ou invité, le point d'accès agit comme un client RADIUS, transmettant les demandes d'authentification à un serveur RADIUS, qui valide les identifiants par rapport à votre annuaire — Active Directory, LDAP ou un fournisseur d'identité cloud — et autorise ou refuse l'accès. Il s'agit du modèle d'authentification 802.1X qui sous-tend les réseaux WPA2-Enterprise et WPA3-Enterprise. Le problème est que le RADIUS traditionnel a été conçu pour une autre époque. Il fonctionne sur UDP — User Datagram Protocol — sur les ports 1812 et 1813. UDP est un protocole sans connexion, ce qui signifie qu'il n'y a pas de handshake, pas d'état de session et, surtout, pas de chiffrement natif. La seule protection entre votre point d'accès et votre serveur RADIUS est un secret partagé — essentiellement un mot de passe — utilisé pour masquer le mot de passe de l'utilisateur en transit à l'aide du hachage MD5. Le MD5, comme la plupart d'entre vous le savent, est cryptographiquement obsolète. Il est cassé depuis des années. Qu'est-ce que cela signifie en pratique ? Cela signifie que sur n'importe quel segment de réseau où un attaquant peut intercepter le trafic RADIUS — ce qui inclut les commutateurs compromis, les appareils malveillants sur votre VLAN de gestion ou tout point situé entre un point d'accès distant et un serveur RADIUS hébergé dans le cloud — il peut potentiellement capturer les échanges d'authentification, tenter des attaques par dictionnaire hors ligne contre le secret partagé et, dans certaines configurations, exposer entièrement les identifiants des utilisateurs. Pour un groupe hôtelier gérant un WiFi invité sur 200 propriétés, ou une chaîne de magasins avec des points d'accès dans chaque boutique renvoyant le trafic vers un serveur RADIUS central via l'internet public, ce n'est pas un risque théorique. C'est une surface d'attaque bien réelle.C'est exactement ce que résout RadSec. RadSec — défini dans la RFC 6614 et mis à jour par la RFC 7360 — encapsule le trafic RADIUS dans un tunnel TLS. Au lieu de l'UDP, il utilise le TCP sur le port 2083. Au lieu d'un secret partagé et de MD5, il utilise une authentification TLS mutuelle avec des certificats X.509. Le client RADIUS et le serveur RADIUS présentent tous deux des certificats, vérifient l'identité de l'autre et établissent une session chiffrée avant tout échange de données d'authentification. TLS 1.3 est la version actuellement recommandée, offrant une confidentialité persistante (forward secrecy) et éliminant une série de vulnérabilités liées aux algorithmes de chiffrement obsolètes. L'effet pratique est significatif. Les données d'identification, les attributs utilisateur et les jetons de session sont chiffrés de bout en bout entre le point d'accès — ou un proxy RadSec — et le serveur RADIUS. Un attaquant interceptant le trafic sur le réseau ne voit que des enregistrements TLS chiffrés. Le secret partagé est toujours présent pour des raisons de compatibilité ascendante, mais il ne joue plus aucun rôle de sécurité significatif — TLS prend tout en charge. Il y a une autre dimension ici qui est de plus en plus pertinente : l'itinérance. La fédération Eduroam, utilisée par les universités et les institutions de recherche à travers l'Europe et au-delà, utilise RadSec depuis des années dans le cadre de son infrastructure d'itinérance interinstitutionnelle. Plus récemment, la norme OpenRoaming de la Wi-Fi Alliance — qui permet une itinérance WiFi transparente entre les sites participants — impose RadSec pour tout le trafic de la fédération. Si vous déployez une infrastructure compatible OpenRoaming, RadSec n'est pas optionnel ; c'est un prérequis. Purple prend en charge OpenRoaming sous sa licence Connect, agissant en tant que fournisseur d'identité au sein de la fédération, et RadSec est au cœur du fonctionnement de cette structure d'itinérance sécurisée. D'un point de vue de la conformité, RadSec est de plus en plus pertinent pour la norme PCI DSS 4.0, qui renforce les exigences relatives à la protection des données d'authentification en transit. Si votre infrastructure WiFi touche à des environnements de cartes de paiement — et c'est fréquemment le cas dans le commerce de détail et l'hôtellerie —, la faille de chiffrement du RADIUS traditionnel est une anomalie qui ne demande qu'à être signalée. Le GDPR exige de la même manière des mesures techniques appropriées pour protéger les données personnelles ; des identifiants d'utilisateurs et des métadonnées de session circulant non chiffrés sur votre réseau sont difficiles à défendre lors d'un audit de protection des données. Parlons maintenant d'architecture. Il existe deux principaux modèles de déploiement pour RadSec. Le premier est le support natif de RadSec sur votre serveur RADIUS et vos points d'accès. FreeRADIUS 3.0 et versions ultérieures prennent en charge RadSec nativement. Microsoft NPS ne prend pas en charge RadSec nativement dans ses versions actuelles, ce qui constitue une contrainte importante pour les organisations exploitant une infrastructure centrée sur Windows. Cisco ISE prend en charge RadSec. Aruba ClearPass prend en charge RadSec. Si votre serveur RADIUS et votre fournisseur de points d'accès prennent tous deux en charge RadSec nativement, c'est la voie la plus simple — configurez les certificats TLS des deux côtés, ouvrez le port TCP 2083 sur votre pare-feu, et vous chiffrez le trafic RADIUS de bout en bout. Le second modèle est un proxy RadSec. Il s'agit du déploiement le plus courant en pratique, en particulier pour les organisations disposant d'une infrastructure RADIUS existante ou d'environnements multi-constructeurs. Un proxy RadSec — radsecproxy étant l'implémentation open-source la plus largement déployée — se positionne entre vos points d'accès et votre serveur RADIUS. Les points d'accès envoient du RADIUS standard sur UDP au proxy sur le réseau local. Le proxy met fin à cette connexion, ré-encapsule le trafic RADIUS dans un tunnel TLS et le transmet au serveur RADIUS en amont via le port TCP 2083. Cette approche vous permet d'ajouter RadSec à une infrastructure existante sans remplacer votre serveur RADIUS, et elle est particulièrement utile lorsque votre serveur RADIUS est hébergé dans le cloud ou accessible via l'internet public. La gestion des certificats est la complexité opérationnelle que vous devez planifier. Vous aurez besoin d'une PKI — Public Key Infrastructure — pour émettre et gérer les certificats X.509 utilisés pour le TLS mutuel. Cela implique une autorité de certification, l'émission de certificats pour chaque client et serveur RADIUS, et un processus de rotation des certificats avant leur expiration. Des certificats qui expirent sans que l'on s'en aperçoive interrompront simultanément l'authentification de tous les utilisateurs de votre réseau — un scénario que vous voulez absolument éviter. Automatisez le renouvellement des certificats à l'aide d'ACME ou de l'API de votre autorité de certification, et configurez des alertes de surveillance bien avant les dates d'expiration. --- [RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER — environ 2 minutes] Laissez-moi vous donner des recommandations pratiques. Premièrement : effectuez un audit avant le déploiement. Cartographiez chaque client RADIUS — points d'accès, concentrateurs VPN, commutateurs faisant du 802.1X — et chaque serveur RADIUS de votre environnement. Identifiez ceux qui prennent en charge RadSec nativement et ceux qui auront besoin d'un proxy. Cet audit met généralement en évidence les équipements obsolètes qui ne prennent pas du tout en charge TLS, et ceux-ci doivent figurer sur votre feuille de route de remplacement. Deuxièmement : commencez par le trafic présentant le risque le plus élevé. Si vous avez du trafic RADIUS qui traverse l'internet public — sites distants, RADIUS hébergé dans le cloud, groupes hôteliers multi-propriétés — c'est votre priorité absolue. Le trafic RADIUS local sur un VLAN de gestion bien segmenté présente un risque plus faible, mais il doit tout de même figurer sur votre feuille de route. Troisièmement : testez minutieusement le TLS mutuel avant la mise en service. Le mode de défaillance le plus courant dans les déploiements RadSec réside dans les erreurs de validation de certificats — Common Names non concordants, certificats intermédiaires expirés ou clients qui ne font pas confiance à l'autorité de certification qui a signé le certificat du serveur. Utilisez openssl s_client pour tester les liaisons TLS avant de basculer le trafic de production. Quatrièmement : ne négligez pas la surveillance. RadSec ajoute une couche de connexion TCP que le RADIUS traditionnel n'a pas. Les échecs de connexion TCP, les dépassements de délai de liaison TLS et les erreurs de certificat se manifesteront par des échecs d'authentification pour vos utilisateurs. Assurez-vous que les journaux de votre serveur RADIUS et de votre proxy alimentent votre SIEM ou votre plateforme de surveillance afin de pouvoir distinguer un problème de connectivité RadSec d'un problème de politique d'authentification. Le piège que je vois le plus souvent est celui des organisations qui déploient RadSec côté serveur mais oublient de mettre à jour leurs règles de pare-feu. Le port TCP 2083 doit être ouvert entre chaque client RADIUS et le serveur ou proxy RADIUS. Si vous avez l'habitude de gérer des règles UDP 1812, le port TCP 2083 peut facilement être oublié lors du processus de modification du pare-feu. --- [Q&A RAPIDE — environ 1 minute] Passons en revue quelques questions que j'entends régulièrement. « Est-ce que RadSec remplace le 802.1X ? » Non. RadSec sécurise la couche de transport entre le point d'accès et le serveur RADIUS. Le 802.1X est le framework d'authentification entre l'appareil client et le point d'accès. Ils fonctionnent à des couches différentes et sont complémentaires. « RadSec est-il pris en charge par tous les fabricants de points d'accès ? » Pas de manière universelle. Cisco, Aruba, Ruckus et Meraki proposent tous différents niveaux de prise en charge de RadSec — vérifiez la version spécifique de votre firmware. En l'absence de support natif, un proxy RadSec est votre solution. « Qu'en est-il de DTLS — RADIUS sur DTLS ? » La RFC 7360 définit RADIUS sur DTLS, qui utilise UDP plutôt que TCP, préservant ainsi certaines des caractéristiques sans connexion du RADIUS traditionnel tout en ajoutant le chiffrement. Il est moins largement déployé que RadSec sur TLS, mais mérite d'être évalué si la latence est une préoccupation dans les environnements à haut débit. « Quel est l'impact sur les performances d'itinérance ? » La connexion TCP de RadSec est persistante, ce qui peut en réalité améliorer les performances d'itinérance dans les environnements fédérés en réduisant la surcharge d'établissement de connexion pour les demandes d'authentification ultérieures. --- [RÉSUMÉ & PROCHAINES ÉTAPES — environ 1 minute] Pour résumer : RadSec est la réponse mature et basée sur des normes à une réelle faille de sécurité du RADIUS traditionnel. Si vous gérez du WiFi d'entreprise à grande échelle — sur plusieurs sites, via Internet ou dans des environnements soumis à la norme PCI DSS ou au GDPR — la question n'est pas de savoir s'il faut déployer RadSec, mais quand et comment. Vos prochaines étapes : auditez votre infrastructure RADIUS cette semaine. Identifiez vos flux de trafic les plus exposés. Vérifiez la documentation de votre serveur RADIUS et de vos points d'accès pour valider le support natif de RadSec. Si vous utilisez FreeRADIUS, vous pouvez mettre en place un déploiement RadSec de test en une journée. Si vous utilisez Microsoft NPS, commencez à évaluer un proxy ou un plan de migration vers un serveur compatible RadSec. La plateforme de Purple est conçue pour s'intégrer aux infrastructures RADIUS d'entreprise, prenant en charge des flux d'authentification sécurisés pour les environnements WiFi d'entreprise et invités. Si vous souhaitez comprendre comment RadSec s'intègre dans votre déploiement spécifique, l'équipe de Purple peut vous accompagner. Merci pour votre écoute. À la prochaine. --- FIN DU SCRIPT