La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
WiFi => Discussion démarrée par: vivien le 08 juillet 2024 à 14:23:06
-
Autre chose qui me semble nouveau avec WPA3 : Mon téléphone refuse de se connecter à ma box SFR (Wi-Fi 5 WPA 2), cela intervient après que ce même mobile a été connecté à un point d'accès Wi-Fi 6 WPA3. J'ai comme l'impression qu'il a noté ce WPA3 et qu'il refuse après de descendre en WPA 2.
Il me paraissait plus simple de mettre toujours le même SSID "IPv6forever" avec le même mot de passe, pour ne pas reconfigurer tous mes équipements (cela fait de nombreuses années et box que j'utilise ce SSID).
Note : a aucun moment les deux points d'accès qui portent le même SSID sont actifs simultanément.
(https://lafibre.info/testdebit/android/202407_wifi_connexion_impossible.webp)
En oubliant le réseau et en rentrant de nouveau le mot de passe, mon mobile Android arrive à s'y connecter.
J'utilise un Google Pixel 6 sous Android 14.
-
Cela doit être une protection contre les attaques par repli (downgrade attack).
Sur le wifi cela consiste à mettre en place un AP malveillant avec le même SSID que le réseau qu'on veut attaquer, mais qui ne gère que WPA2 afin d'exploiter les vulnérabilités de ce dernier.
-
Cette protection contre les attaques par repli vers TLS 1.2 n'est pas présente dans Windows 11 ou Ubuntu 24.04.
Seul mon Android 14 a refusé de se connecter à un point d'accès qui est passé de TLS 1.3 à TLS 1.2.
-
Cela doit être une protection contre les attaques par repli (downgrade attack).
Cette protection présente sur Android et iOS, mais pas sur Windows 10 / Windows 11 / Ubuntu 24.04.
Sur Android comme iOS, impossible de se connecter simplement sur un point d'accès WPA2 qui a été dans le passé WPA3 ou WPA2/WPA3.
-
Attends je n'ai pas tout compris. Tu pense que c'est le SSID qui sert de point de repère à l'appareil pour refuser la connexion ?
C'est quand même sacrement courant d'utiliser le même SSID/password sur plusieurs sites et donc avec des technos potentiellement très différentes.
Ça serait pas plutôt le BSSID/adresse MAC ?
-
Oui, c'est le SSID.
J'ai pour habitude de changer le SSID pour "IPv6forever"
Quand j'ai déménagé cet été, j'ai changé le SSID de ma nouvelle box pour mon SSID habituel "IPv6forever".
Tous mes équipements se sont connectés directement sur la nouvelle box, normal.
Quelques jours après, je suis revenu dans mon ancien appartement où la box était encore là et j'ai été surpris que la connexion soit impossible avec mon Android.
C'est donc le SSID qui est utilisé et il ne faut pas mélanger sur un même SSID WPA2 et WPA3.
-
C'est donc le SSID qui est utilisé et il ne faut pas mélanger sur un même SSID WPA2 et WPA3.
Si tu désires te connecter à une Box, ton périphérique (un mobile ou autre chose) va se connecter avec le paramétrage qu'il a stocké et déjà utilisé lors de la précédente connexion. Si tu changes les caractéristiques de ta Box, ton périphérique ne va plus pouvoir se connecter à cause de ce qui a été stocké précédemment. La seule solution est alors de refaire une demande de connexion depuis ton périphérique (ton mobile) en saisissant à nouveau le SSID/Password. C'est ce que j'ai constaté avec tous mes périphériques (Asus, Raspberry Pi, ESP32, dongle WiFi) quand je bidouille le WiFi de la Box. Ce n'est pas, il me semble, une protection contre des attaques mais le fonctionnement normal du WiFi.
-
Ce n'est pas, il me semble, une protection contre des attaques mais le fonctionnement normal du WiFi.
Relis bien la discussion.
Le fonctionnement normal du wifi est que l'équipement se connecte avec les infos qu'il a en mémoire, donc SSID et pass, et ce sans se préoccuper de qui il a en face.
-
Ici, quand un point d'accès connu passe de WPA3 à WPA2, on ne peut pas se connecter simplement en saisissant le mot de passe : il faut lister les points d'accès et oublier la connexion à ce SSID, avant de pouvoir de nouveau s'y connecter.
-
J'ai bien relus la discussion et je ne comprends pas en quoi ma réponse n'est pas conforme.
En oubliant le réseau et en rentrant de nouveau le mot de passe, mon mobile Android arrive à s'y connecter.
C'est ce que j'ai aussi constaté chez moi. Et donc, c'est quoi le problème ?
Le fonctionnement normal du wifi est que l'équipement se connecte avec les infos qu'il a en mémoire, donc SSID et pass, et ce, sans se préoccuper de qui il a en face.
Justement, ce comportement que tu qualifies de normal ne fonctionne pas dans le cas que soulève vivien. Il y a bien autre chose qui doit bloquer l'accès. Je ne sais pas, peut-être une adresse MAC ?
-
La seule solution est alors de refaire une demande de connexion depuis ton périphérique (ton mobile) en saisissant à nouveau le SSID/Password. C'est ce que j'ai constaté avec tous mes périphériques (Asus, Raspberry Pi, ESP32, dongle WiFi) quand je bidouille le WiFi de la Box.
Il ne s'agit pas ici de bidouiller le wifi de la box, le souci se produit uniquement lorsque l'équipement bascule d'un point d'accès en WPA3 à un autre en WPA2 même SSID et pass
-
J'avais bien compris que Vivien n'a aucun problème de connexion à sa BOX dans son nouvel appartement mais qu'il n'a pas pu se connecter à l'autre BOX de son ancien appartement, ayant tous les deux le même SSID "ipv6forever" et le même mot de passe.
Ce que Vivien n'a pas dit, si ce sont les mêmes modèles de BOX ou pas. Oui, j'ai bien compris que l'une des BOX est configuré WPA/WPA2 et l'autre uniquement WPA2, d'où ce problème de basculement qui n'a pas pu se faire.
-
Ce n'est pas le modèle de box ou du point d'accès qui bloque la connexion.
A mon avis, c'est plutôt du coté de l'équipement mobile que le blocage serait réalisé
-
Il s'agit simplement d'une protection côté terminal, pour éviter les attaques par downgrade comme le spécifie Vivien (WPA ou WPA2 au lieu de WPA3 dans notre cas).
Concrètement, lorsqu'un terminal (PC, smartphone, etc...) trouve un SSID connu, et précédemment sécurisé avec WPA3, il va refuser de s'y connecter. Le même mécanisme existe sur le web pour HTTPS avec HSTS.
Ca évite qu'un attaquant bloque le protocole sécurisé (WPA3, HTTPS) et force l'usage du protocole non sécurisé (WPA/WPA2, HTTP).
-
Ce que Vivien n'a pas dit, si ce sont les mêmes modèles de BOX ou pas.
J'avais une box FTTH RED Wi-FI 5 WPA2 dans mon ancien appartement, et maintenant, je suis en 5G Home Orange, avec une Flybox Wi-Fi 6 WPA3.
-
@ Vivien : merci pour l'information. :)
Si avant, tu pouvais te connecter sur ta FlyBox en WPA3, je suppose que ton mobile essaye encore de se connecter en WPA3 mais sur ta RedBySFR, vu que tu n'as pas modifié le SSID/Password de tes BOX et de ton mobile. Celui-ci ne doit même pas chercher à basculer vers le WPA2 car la dernière connexion s'est faite en WPA3. Le mobile suppose que le bon protocole est WPA3, pas le WPA2 et n'a aucune raison de faire ce changement vu qu'il a enregistré le fait qu'avec WPA3 la connexion avait pu se faire.
A mon avis, c'est plutôt du coté de l'équipement mobile que le blocage serait réalisé
Difficile de savoir si c'est la BOX qui bloque ou si c'est le mobile. De toute façon, il y a des informations stockées dans les deux, qui peuvent entrer en conflit lors d'une nouvelle connexion. Je ne crois pas trop que le mobile reformule une demande de connexion s'il possède déjà les caractéristiques de la dernières qui s'est bien passée.
Robin4002 ainsi que FlorianSG suppose un mécanisme de protection "downgrade attack (https://fr.wikipedia.org/wiki/Attaque_par_repli)". Oui mais Vivien dit :
Cette protection contre les attaques par repli vers TLS 1.2 n'est pas présente dans Windows 11 ou Ubuntu 24.04.
Seul mon Android 14 a refusé de se connecter à un point d'accès qui est passé de TLS 1.3 à TLS 1.2.
laisse supposer que cela se passe sur son Androïd 14, s'il est bien question du mécanisme de protection qui bloque l'accès.
-
Il s'agit simplement d'une protection côté terminal, pour éviter les attaques par downgrade comme le spécifie Vivien (WPA ou WPA2 au lieu de WPA3 dans notre cas).
Concrètement, lorsqu'un terminal (PC, smartphone, etc...) trouve un SSID connu, et précédemment sécurisé avec WPA3, il va refuser de s'y connecter. Le même mécanisme existe sur le web pour HTTPS avec HSTS.
Ca évite qu'un attaquant bloque le protocole sécurisé (WPA3, HTTPS) et force l'usage du protocole non sécurisé (WPA/WPA2, HTTP).
C'est compréhensible si on parle de deux appareils toujours identiques qui tentent de se parler. Mais utiliser le simple SSID c'est une idée idiote puisque ce dernier n'est pas lié à un appareil, ni même en réalité à un unique réseau. C'est d'autant plus problématique que ça veut dire qu'on ne peut plus protéger par WPA et mot de passe de grand réseaux publiques qui s'appuient sur des dizaines de produits réseaux différents.
-
Mais utiliser le simple SSID c'est une idée idiote puisque ce dernier n'est pas lié à un appareil, ni même en réalité à un unique réseau.
Si tu te mets à la place de l'utilisateur, ca a beaucoup de sens : de leur point de vue, le SSID est "le réseau". Ils ignorent combien d'AP il content, où ils sont placés, qui le maintient, quel plan de fréquence il utilise, etc.
Pour la pluspart, "le wifi", c'est l'AP intégré à leur box ou à celle de leurs amis.
Il y a toujours la possibilité de supprimer le réseau et de scanner à nouveau le QR code, dans le cas où certains AP d'un grand réseau ne peuvent pas être mis à jour pour supporter WPA3. C'est un peu compliqué, j'en conviens.
Une piste pour mettre à jour des AP dont le firmware n'est pas maintenu est d'y installer OpenWRT. J'ai du WPA3 sur mes TP-Link Archer C7 et même sur mon WNDR4300 qui a plus de 10 ans.
-
C'est compréhensible si on parle de deux appareils toujours identiques qui tentent de se parler. Mais utiliser le simple SSID c'est une idée idiote puisque ce dernier n'est pas lié à un appareil, ni même en réalité à un unique réseau. C'est d'autant plus problématique que ça veut dire qu'on ne peut plus protéger par WPA et mot de passe de grand réseaux publiques qui s'appuient sur des dizaines de produits réseaux différents.
C'est à mon avis là une limite du WPA2/3 Personnel, qui n'as pas été conçu pour être exploité sur de grands réseaux hétérogènes. La théorie voudrait que ce genre de réseaux soit ouvert (hot-spot avec portail captif), ou sécurisé via WPA2/3 Entreprise avec authentification centralisée. Dans ce dernier cas je ne sais d'ailleurs pas si il est possible de mixer les deux génération sur un même réseau, et si le même comportement est attendu des terminaux en cas de transition WPA3 vers WPA2.
Plus généralement, mettre à jour une grande infra (configuration, sécurité, etc...) c'est un projet à part entière, qui se planifie, avec des analyses d'impact, PoC, et autres joyeusetés. Mais c'est malheureusement bien trop souvent oublié...
-
Une piste pour mettre à jour des AP dont le firmware n'est pas maintenu est d'y installer OpenWRT. J'ai du WPA3 sur mes TP-Link Archer C7 et même sur mon WNDR4300 qui a plus de 10 ans.
En creusant le sujet, j'ai l'impression que le WPA 2 ou WPA 3 peut être pris en charge logiciellement par le driver Wi-Fi : J'ai une carte Wi-Fi Qualcom 802.11b/g de 2008 qui gère bien WPA3 (je ne parle pas de WPA3-TM Transition Mode, mais du vrai WPA3.
Une autre carte Wi-Fi Intel de 2005 (les spec de 2005 ne mentionnement pas le WPA2) gère le WPA3-TM sous Linux, mais pas sous Windows 10 où elle est limitée au WPA2. Le vrai WPA3 ne fonctionne par contre ni sous Windows, ni sous Linux.
-
En creusant le sujet, j'ai l'impression que le WPA 2 ou WPA 3 peut être pris en charge logiciellement par le driver Wi-Fi
Oui, c'est bien le cas pour la majeure partie des cartes sur lesquelles le driver/supplicant est responsable de la séquence d'authentification et de la gestion des clefs (chips dit "softmac").
Sur des cartes où ces fonctionnalités sont implémentés dans le firmware, c'est différent et la connexion en WPA3 échoue lorsque demandée par le driver (cas du BCM43224 "fullmac" de mon vieux macbook, par exemple).
-
Comment on sait si c'est du "softmac" ou "fullmac" ?
C'est possible via une commande sous Linux de le détecter ?
Pourquoi le driver de la carte Intel PRO/Wireless 3945ABG arrive à se connecter sur un AP WPA3-TM Transition Mode (configuration qui est de plus en plus mis par défaut sur les box opérateur, sous le nom "WPA2/WPA3") sous Linux et pas sous Windows 11 ?
J'ai lu sur le wiki de Debian, qu'un firmware non-libre est nécessaire (https://wiki.debian.org/fr/iwlegacy) : Intel aurait ajouté le support du WPA3-TM sur le firmware pour Linux et pas celui pour Windows ?
Sur le page Wikipedia Intel PRO/Wireless (https://en.wikipedia.org/wiki/Intel_PRO/Wireless), il est indiqué que le micrologiciel binaire n'a toujours pas obtenu de licence compatible avec les principes du logiciel libre.
(https://lafibre.info/testdebit/wifi/202408_wifi_intel_3945abg_linux_kernel_module.webp)
Le pilote proposé par Windows 11 (Intel ne propose pas de driver pour Windows 8 et plus récent, car il est intégré à Windows).
(https://lafibre.info/testdebit/wifi/202408_wifi_intel_3945abg_windows11_pilote_1.webp) (https://lafibre.info/testdebit/wifi/202408_wifi_intel_3945abg_windows11_pilote_2.webp) (https://lafibre.info/testdebit/wifi/202408_wifi_intel_3945abg_windows11_pilote_3.webp)
Cette carte Wi-Fi est une antiquité et la doc ne mentionne pas le support du WPA2. J'imagine que ce n'est donc pas un support hardware et que comme WPA2 a été mis dans le pilote, il serait possible de mettre le WPA3 ?
(https://lafibre.info/testdebit/wifi/200512_wifi_intel_3945abg_1.webp)
(https://lafibre.info/testdebit/wifi/200512_wifi_intel_3945abg_2.webp)
(https://lafibre.info/testdebit/wifi/200512_wifi_intel_3945abg_3.webp)
-
Comment on sait si c'est du "softmac" ou "fullmac" ?
Les drivers fullmac n'utilisent pas mac80211 sous linux
(https://pix.milkywan.fr/eARHZCeI.png)
J'imagine qu'en regardant les modules chargés on doit pouvoir s'en rendre compte donc. Sur d'anciens équipements j'avais du fullmac avec broadcom.
Il y a une liste ici : https://wifidiving.substack.com/p/linux-kernel-wifi-stack-basics (https://wifidiving.substack.com/p/linux-kernel-wifi-stack-basics)
(https://pix.milkywan.fr/4le3msgy.png)
-
En effet. Sur un autre laptop toujours en broadcomm, qui lui utilise un driver softmac :
# lspci -k
[...]
06:00.0 Network controller [0280]: Broadcom Limited BCM4352 802.11ac Wireless Network Adapter
Kernel modules: bcma
[...]
Le driver de cette carte est bcma.
# lsmod | grep brcm
brcmsmac 696320 0
brcmutil 20480 1 brcmsmac
cordic 16384 1 brcmsmac
mac80211 1249280 1 brcmsmac
cfg80211 970752 2 mac80211,brcmsmac
bcma 73728 1 brcmsmac
bcma depend de brcmsmac ("smac" pour softmac je suppose), qui lui-même dépend de mac80211. C'est donc bien un softmac.
-
Pourquoi le driver de la carte Intel PRO/Wireless 3945ABG arrive à se connecter sur un AP WPA3-TM Transition Mode (configuration qui est de plus en plus mis par défaut sur les box opérateur, sous le nom "WPA2/WPA3") sous Linux et pas sous Windows 11 ?
J'ai lu sur le wiki de Debian, qu'un firmware non-libre est nécessaire (https://wiki.debian.org/fr/iwlegacy) : Intel aurait ajouté le support du WPA3-TM sur le firmware pour Linux et pas celui pour Windows ?
Sur le page Wikipedia Intel PRO/Wireless (https://en.wikipedia.org/wiki/Intel_PRO/Wireless), il est indiqué que le micrologiciel binaire n'a toujours pas obtenu de licence compatible avec les principes du logiciel libre.
Le pilote proposé par Windows 11 (Intel ne propose pas de driver pour Windows 8 et plus récent, car il est intégré à Windows).
Le firmware des contrôleurs est bien souvent chargé par le driver (ca évite de mettre de la mémoire flash additionnelle pour stocker le firmware ainsi que de devoir développer une méthode de flash + récpération du matériel en cas d'erreur de flashage).
Bien souvent, le firmware et le driver sont étroitement liés, car les fonctionnalités supportées par le firmware ainsi que l'interface de comm qu'il expose au driver peut changer avec les versions.
Je suppose que le firmware packagé sous Ubuntu (dans linux-firmware, je suppose?) est plus récent que celui inclus dans le driver Windows 11 ? As-tu éventuellement moyen de récupérer un driver plus récent pour cette carte sur le site d'intel ?
-
Sur le site d'Intel, il n'y a pas de driver disponibles, ils se contentent de te dire que sous Windows comme sous Linux, les pilotes sont intégrés au système d'exploitation pour Windows 8 / 8.1 / 10 /11 / Linux.
Les pilotes pour Windows 2000 / XP / Vista / 7 ne sont même plus disponibles sur le site d'Intel.
=> https://www.intel.fr/content/www/fr/fr/support/products/50517/wireless/legacy-intel-wireless-products/intel-prowireless-products/intel-pro-wireless-3945abg-network-connection.html
Ce qui m'intrigue avec cette veille carte, c'est le comportement différent entre Linux et Windows pour le WPA3-TM.
Je cherche à comprendre à quoi est liée cette incompatibilité qui selon un acteur représente 15% des terminaux du parc (comme indiqué dans le message ci-dessous, l'incompatibilité n'est pas sur les PC, mais l'intérêt d'avoir une carte bien documentée qui a ce pb est de pouvoir chercher alors que quand une imprimante n'est pas compatible WPA3-TM, tu ne peux que constater, sans savoir si une mise à jour pourrait corriger le pb).
Le WPA3-TM est conçu pour offrir une compatibilité avec tous les terminaux WPA2 et WPA3, mais en réalité, ce n’est pas systématiquement le cas : ce mode n’était pas supporté par approximativement 15% des équipements en parc.
Les 15% de terminaux Wi-Fi non compatibles sont des terminaux non compatibles avec WPA3-TM, mais compatibles WPA2.
Sur un point d'accès Wi-Fi 7, on risque donc de perdre 15% des terminaux (smartphones, imprimantes, mais aussi des plus récents, principalement dans les accessoires low cost : chargeurs de voiture et bien entendu une multitude d’équipements IoT). Ils ont tous le point commun d'être antérieures à l'année 2020.
Je n'ai pas dit que tous les terminaux antérieurs à 2020 ne fonctionnement pas en mode WPA3-TM, mais que ceux qui ne fonctionnement pas en mode WPA3-TM sont fabriqués avant cette date.
Si vous avez des informations, je suis preneur.
C'est important car en Wi-Fi 7, le WPA2 ne devrait plus être disponible, il ne reste que le WPA3-TM et WPA3.