Si nous devons crypter le message plutôt que la méthode de transfert, pourquoi nous soucions-nous de la sécurité wifi? Est-ce juste un théâtre de sécurité?
La plupart des réponses à cette question sur la sécurité de l'Internet par satellite se résument à: le cryptage du message est plus important que le cryptage de la méthode de transfert.
Cependant, il semble y avoir beaucoup d'attention sur wi-fisecurity .
Pour quels modèles de menace la sécurité Wi-Fi est-elle importante et pour quels modèles de menace s'agit-il uniquement d'un théâtre de sécurité?
- Empêcher les autres d'utiliser mon wi-fi? Cela pourrait probablement être fait (de manière plus sûre?) En autorisant explicitement chaque périphérique sur le routeur. À l'époque (début des années 2000), je devais dire à mon université l'adresse MAC pour chaque appareil avec lequel je voulais utiliser Internet, bien que ce soit pour Internet filaire (il n'y avait pas encore de wifi sur tout le campus).
- Empêcher les autres de renifler sur mon wi-fi? Mais devrions-nous plutôt chiffrer sur une couche supérieure (comme HTTPS)?
- Y a-t-il d'autres modèles de menace pertinents ici?
Le chiffrement du réseau protège contre un ensemble de menaces différent du chiffrement de la couche application comme TLS.
En particulier, le cryptage réseau comme le cryptage Wifi est principalement conçu pour protéger un attaquant local de la possibilité de surveiller les modèles de réseau (en enregistrant avec qui vous établissez des connexions et en découvrant quels appareils se trouvent sur le réseau local), en observant/altérant des messages de bas niveau comme ARP/DNS, et la protection des diffusions réseau contre les appareils qui ne sont pas censés se trouver sur le réseau, et contre la falsification ou les interférences sélectives.
TLS ne protège pas les paquets TCP/IP de bas niveau, qui divulguent des informations telles que l'adresse IP de la machine avec laquelle vous vous connectez, et la négociation TLS, de par sa conception, entraîne également la fuite d'un certain nombre d'informations sur la connexion, comme l'indication de nom de serveur (SNI) ) entête.
L'effet secondaire de devoir faire tout cela est que le matériel Wifi doit déjà avoir suffisamment de code et de puissance de traitement pour gérer le chiffrement, il devient donc plus facile de chiffrer tous les paquets wifi plutôt que de déterminer de manière sélective ce qui a besoin de protection ou non. Cela présente également l'avantage secondaire que la connexion HTTP non sécurisée sera toujours au moins marginalement protégée, même si au moins pour protéger les utilisateurs de l'infrastructure les uns des autres, mais pas du fournisseur d'infrastructure.
Le chiffrement du réseau est conçu pour protéger le réseau, pas le service. Le chiffrement des applications est conçu pour protéger la connexion au service, mais il ne protège pas le réseau. Ils se complètent, mais aucun ne rend complètement l'autre inutile.
Pourquoi n'autorisons-nous pas simplement chaque appareil terminal?
Nous faisons. Enfin un peu. Le modèle traditionnel de clé pré-partagée (PSK) authentifie les appareils en leur donnant accès au PSK. Ce n'est pas la seule façon de faire les choses, et votre question mentionne les adresses MAC. Cela n'est généralement pas sûr, car les appareils sans fil diffusent nécessairement leur adresse MAC avec chaque paquet qu'ils envoient. Les adresses MAC sont également modifiables, ce qui signifie qu'un attaquant peut simplement cloner l'adresse MAC d'un appareil autorisé pour contourner les filtres basés sur MAC.
La meilleure approche est les certificats clients, qui sont effectués pour la sécurité WPA2-Enterprise. C'est une bien meilleure approche en termes de sécurité, mais l'inconvénient est que chaque appareil doit le prendre en charge. De nombreux appareils grand public (et même certains appareils professionnels bas de gamme) ne prennent pas en charge WPA2-Enterprise (par exemple, votre Nintendo Switch, votre imprimante sans fil, etc.).
Pourquoi chiffrons-nous sur une couche inférieure si nous pouvions chiffrer dans une couche supérieure?
Qu'est-ce qui vous fait penser que les couches supérieures sont en quelque sorte préférables? Le chiffrement dans les couches inférieures signifie que même les protocoles qui ne sont pas chiffrés seront toujours "quelque peu" sûrs lorsqu'ils sont utilisés dans un réseau sans fil. Le chiffrement dans une couche supérieure nécessite que chaque application gère elle-même le chiffrement.
De plus, le cryptage des données deux fois ne réduit pas le niveau de sécurité, et le cryptage est devenu tellement optimisé que l'impact sur les performances est négligeable pour tous, sauf les appareils les plus bas de gamme (pensez à l'IoT, etc.).
N'est-ce pas tout le théâtre de la sécurité?
Le "théâtre de la sécurité" est la pratique consistant à investir dans des contre-mesures destinées à procurer le sentiment d'une sécurité améliorée tout en faisant peu ou rien pour y parvenir.
Un excellent exemple est le TSA. De nombreuses mesures qu'ils ont mises en place peuvent être contournées, ou sont tout simplement ridicules, telles que tapoter les jeunes enfants, les nourrissons ou les personnes âgées. Il y en a plus, et en fait Wikipédia a ne belle liste de quelques points plus fortement critiqués.
Si vous avez visité un plus grand aéroport récemment, vous aurez certainement des souvenirs très vivants de personnes faisant la queue, attendant d'être tapotées et d'être informées de raisons ridicules pour lesquelles leur ceinture pourrait être utilisée pour étrangler le pilote ou quelque chose de semblable à il. Tout cela est un coût pour la population, pour les utilisateurs réels de l'aéroport. Rien de tout cela n'augmente particulièrement le coût pour un attaquant, car il pourrait contourner ces mesures avec une relative facilité.
Maintenant que nous avons défini Security Theater, pensez au chiffrement sans fil pendant un moment. Vous devez taper une clé générée aléatoirement une fois, ce qui prendra entre 30 et 60 secondes, selon la durée de la clé et la vitesse à laquelle vous pouvez la taper. L'avantage est qu'un attaquant devrait capturer une poignée de main puis passer un certain temps entre 30 secondes et 10 ^ 30 fois la durée de vie de l'univers pour casser la clé. C'est certainement un avantage de sécurité substantiel, et n'est donc pas pas Security Theater .
En plus des bonnes réponses déjà publiées, j'ajouterais que le fait d'avoir des personnes sur votre WiFi n'est pas seulement une menace pour la confidentialité de vos échanges.
C'est également une menace pour vos points de terminaison, car l'attaquant peut désormais accéder à toutes sortes d'appareils qui autrement ne seraient pas exposés de l'extérieur (IoT, imprimantes, ordinateurs eux-mêmes, NAS, serveurs, etc.). Toute vulnérabilité sur ces points finaux se retrouverait dans une brèche, puis un mouvement latéral vous causerait des ennuis.
Vous voulez donc que les gens soient exclus de votre réseau:
- Pour éviter de renifler - mais vous avez raison de dire que l'utilisation d'un VPN ou similaire vous sécuriserait contre cette menace
- Et aussi pour éviter des attaques directes et directes sur des choses qui seraient autrement inaccessibles de l'extérieur!
La sécurité Wifi existe depuis bien plus longtemps que la norme pour tous les sites Web utilisant https. Remontez environ 5 ans en arrière et une très grande partie d'Internet n'était pas chiffrée. La sécurité Wifi fournissait un avantage très réel et important à cette époque, c'est pourquoi le conseil de ne pas utiliser le café wifi pour des utilisations sensibles était et est un conseil si répandu.
Même maintenant, il existe encore un tas de protocoles comme les DNS qui ne sont pas chiffrés, sauf si vous avez une application qui est récemment passée au DNS via HTTPS. Ces données sont actuellement protégées par la sécurité de votre réseau wifi.
À l'époque (début des années 2000), je devais dire à mon université l'adresse MAC de chaque appareil avec lequel je voulais utiliser Internet.
C'est à peu près aussi sûr que d'utiliser des tags de nom pour authentifier les utilisateurs. Votre adresse MAC est diffusée publiquement et les utilisateurs peuvent changer leur adresse mac en ce qu'ils veulent, donc tout attaquant doit écouter le trafic wifi et copier l'adresse mac d'un utilisateur légitime.
Pour fournir un point de vue contraire, le célèbre cryptographe Bruce Schneier a publié un article sur pourquoi il a un réseau wifi ouvert . Cet article a généré un grand débat (liens à la fin de cet article), avec certains professionnels de la sécurité soutenant et certains opposés. Le principal argument de sécurité de Schneier pour ne pas crypter son propre wifi est qu'il veut utiliser ses appareils mobiles sur d'autres réseaux wifi, mais qu'il ne fait pas confiance à ces réseaux, et qu'il doit donc sécuriser les appareils de toute façon:
"Je suis également insensible à ceux qui disent que je mets mes propres données en danger, car les pirates pourraient se garer devant ma maison, se connecter à mon réseau ouvert et écouter sur Internet trafic ou pénétrer dans mes ordinateurs. Cela est vrai, mais mes ordinateurs sont beaucoup plus à risque lorsque je les utilise sur les réseaux sans fil dans les aéroports, les cafés et autres lieux publics. Si je configure mon ordinateur pour qu'il soit sécurisé quel que soit le réseau sur lequel il se trouve , alors cela n'a pas d'importance. Et si mon ordinateur n'est pas sécurisé sur un réseau public, sécuriser mon propre réseau ne réduira pas beaucoup mes risques. Oui, la sécurité informatique est difficile. Mais si vos ordinateurs quittent votre maison, vous devez le résoudre de toute façon. Et toute solution s'appliquera également à vos machines de bureau. "
Il a également un deuxième argument , ce qui revient à l'incapacité d'empêcher le mot de passe wifi de fuir par inadvertance à des tiers une fois qu'il a été partagé:
"les utilisateurs se connectent aux réseaux Wi-Fi à partir de leur Android et sauvegardent ces mots de passe avec tout le reste dans le cloud de Google, que Google accumule un énorme base de données des mots de passe Wi-Fi dans le monde. Et bien que ce ne soit pas tous les mots de passe Wi-Fi dans le monde, c'est presque certainement un grand pourcentage d'entre eux. En laissant de côté les intentions de Google concernant cette base de données, c'est certainement quelque chose que le gouvernement américain pourrait forcer Google remet une lettre de sécurité nationale. "
Si vous avez un accès physique à un réseau, vous pouvez le rendre complètement inutilisable. C'est particulièrement un problème pour les réseaux sans fil, car vous n'avez aucun moyen de limiter l'accès physique; cela devient également un peu un problème dans l'hébergement moderne "cloud privé" - vous n'avez besoin de compromettre qu'une seule machine pour compromettre l'ensemble du réseau.
La méthode la plus simple serait l'inondation ARP ou l'usurpation d'identité. Continuez simplement à envoyer des demandes ARP et des réponses erronées aux demandes ARP. Une seule machine peut rendre l'ensemble du réseau inutilisable, en utilisant les protocoles de très bas niveau sans pratiquement aucune protection. La seule façon d'éviter cela est de le gérer à un niveau encore plus bas - le protocole Wi-Fi (particulier) lui-même. L'usurpation ARP en particulier est particulièrement amusante, car il est difficile de vider le cache ARP, et comme de nombreux routeurs Wi-Fi ne permettent que la configuration via le réseau, il peut être difficile de corriger l'accès.
Cela dit, je ne connais aucun cas où cela a été utilisé dans une véritable attaque DOS sur un réseau Wi-Fi. C'est plus la chose que vous feriez à un voisin ennuyeux qu'une attaque sérieuse.
La réponse de Lie Ryan est juste, mais même ces avantages n'existent que si la clé ("mot de passe wifi") est forte et non largement partagée, auquel cas un attaquant intéressé à surveiller ou interférer avec vos opérations pourra de toute façon avoir accès . Le but principal des mots de passe wifi est d'empêcher le mooching occasionnel du service - monopolisation de la bande passante, utilisation du service pour des activités criminelles qui pourraient être liées à tort à vous, etc.