Pourquoi le WiFi ouvert n'est-il pas chiffré?
Autant que je sache, les réseaux WiFi qui ne nécessitent aucun mot de passe envoient du trafic via l'air non crypté. Ceux qui nécessitent un mot de passe chiffrent chaque connexion de manière unique, même s'ils utilisent tous le même mot de passe.
Si c'est vrai, je ne comprends pas pourquoi. Exiger un mot de passe pour l'accès et crypter les connexions semble être un problème totalement différent.
Sont-ils vraiment liés de cette façon? Si oui, y a-t-il une raison que je ne vois pas? Certains routeurs peuvent-ils être configurés pour autoriser l'accès public sans mot de passe, tout en chiffrant les connexions des utilisateurs pour empêcher les attaques de style Firesheep?
Mise à jour
Certaines réponses ont dit ou laissé entendre que le mot de passe est un "secret partagé" nécessaire qui permet le cryptage. Mais ce n'est pas nécessaire. Ce problème a été résolu publiquement en 1976.
La méthode d'échange de clés Diffie – Hellman permet à deux parties qui ne se connaissent pas mutuellement d'établir conjointement une clé secrète partagée sur un canal de communication non sécurisé. ( http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange )
La question (pour la plupart des gens) est un oxymore. Par définition, les gens penseront que "WiFi ouvert" signifie "WiFi non chiffré. Pour moi, vous semblez demander" Pourquoi les gens qui ont écrit la manière standard 802.11 en 1997 ont-ils pris les décisions ils l'ont fait? "
La réponse courte - nous ne pouvons le découvrir qu'en leur demandant (ou en voyant s'il y a des documents de discussion flottant sur Internet).
Cependant, nous pouvons discuter de la partie Firesheep de la question. Une attaque "Firesheep" est un type d'attaque spécifique où les cookies qui authentifient un utilisateur sur un site sont copiés par un attaquant.
La seule exigence est que les cookies puissent être obtenus par l'attaquant - et donc les réseaux WiFi utilisant WEP, WPA ou WPA2 avec une seule clé pré-partagée sont vulnérables , si l'attaquant possède la clé . Et bien sûr, de nombreuses petites entreprises fournissent un accès WiFi à l'aide d'une seule clé.
Avoir de "meilleurs" points d'accès est un moyen coûteux de résoudre ce problème et laissera toujours les utilisateurs vulnérables au scénario d'attaque ci-dessus (où l'attaquant peut utiliser empoisonnement ARP plus un man-in -the-middle attaque contre les sites HTTP uniquement).
Par conséquent, en ce qui concerne les solutions, la meilleure et la plus utile serait la mise en œuvre généralisée de HTTPS ( comme recommandé par le créateur de Firesheep, Eric Butler)
Firesheep n'a rien à voir avec le cryptage WiFi. Si vous et moi étions tous les deux sur une connexion WiFi cryptée, je serais toujours en mesure de déclencher vos données.
Ce que Firesheep fait se produit au niveau du routeur. Il n'intercepte pas les ondes dans l'air (enfin, pas exactement)
Fondamentalement, il exécute une attaque surpation ARP . Ce type d'attaque peut également être exécuté sur un réseau LAN; il s'agit de nourrir le routeur de mensonges sur l'adresse MAC correspondant à une IP donnée. Lorsqu'un routeur souhaite distribuer un paquet à une IP donnée, il doit savoir à qui appartient cette IP. S'il n'a pas ces données dans son cache, il diffuse un message demandant ces détails. N'importe qui sur le sous-réseau peut répondre à la diffusion et dire que l'adresse IP est la leur, même si elle ne l'est pas. En utilisant cela, un attaquant peut s'asseoir directement entre le routeur et la victime dans le canal de communication.
Pour être clair: il s'agit d'un problème avec TCP/IP (le protocole qui pilote la mise en réseau). Pas avec le WiFi.
Les autres réponses ont déjà expliqué que les attaques de type Firesheep (essentiellement MitM trhough ARP spoofing ) n'ont rien à voir avec le WiFi lui-même. Il s'agit d'un problème link-layer .
Quant à savoir pourquoi les réseaux WiFi ouverts n'ont pas de cryptage. Eh bien, ils ne le font tout simplement pas. Je ne sais pas vraiment pourquoi ils ont décidé de ne pas le faire, je ne peux que spéculer. Une raison très évidente est les attaques MitM, car n'importe qui pourrait usurper l'identité du point d'accès (AP) et négocier la connexion cryptée avec les victimes. Ce qui nous amène à un problème PKI , si les propriétaires de points d'accès acquièrent des certificats de confiance pour leurs points d'accès. Mais cela va à l'encontre de l'objectif global d'un réseau Wifi ouvert, car il vous faudrait alors vérifier l'identité de l'AP.
Comment savons-nous que "JFK Airport AP" est vraiment le point d'accès de l'aéroport JFK? Faut-il émettre des certificats pour les points d'accès appelés "JFK AP"? Cela mènerait-il à des attaques d'ingénierie sociale? Dois-je créer mes propres certificats puis demander à mes amis de leur faire confiance lorsqu'ils se connectent à mon réseau? Maintenant, bien sûr, on pourrait dire que nous pouvons utiliser le modèle de confiance à la première utilisation, mais cela ne fonctionne pas pour les réseaux WiFi dans les parcs, les aéroports ou dans la rue.
Il y a quelques propositions pour résoudre le problème, comme ne proposition des étudiants de l'Ohio State University , ils l'appellent l'authentification factice
Notre solution utilise les algorithmes de chiffrement à clé symétrique existants, par exemple, TKIP et AES, qui sont déjà utilisés dans les produits WPA et 802.11i) pour protéger les trames sans fil de l'usurpation d'identité et de l'écoute clandestine. les algorithmes de chiffrement existants, des clés de chiffrement sont évidemment nécessaires. Dans cette section, nous proposons d'abord un nouvel algorithme d'établissement de clé d'authentification factice. Ensuite, nous utilisons la clé de session établie pour protéger les trames sans fil.
Ce que j'aime vraiment. Si vous y réfléchissez un peu, vous verriez que cela résoudrait le problème de reniflement et les problèmes d'emprunt d'identité AP (comme avec l'usurpation ARP) avec le utilisation de certificats émis par l'AC.
Nous supposons que chaque AP a une paire de clés publique-privée, notée pk et sk , par exemple, les clés RSA. La clé publique est contenue dans un certificat signé par une autorité de certification ou un certificat auto-signé.
Bien sûr, cela nécessiterait la mise à niveau de tous les points d'accès WiFi existants et des correctifs des systèmes d'exploitation. Pas une chose facile à faire.
Vous avez raison: ce n'est pas le même problème: l'authentification par mot de passe et le chiffrement symétrique sont des concepts totalement indépendants qui peuvent être mis en œuvre sans l'autre. Cependant, un mot de passe est l'une des nombreuses façons de produire la clé nécessaire au fonctionnement du cryptage.
Une connexion cryptée telle que celle entre votre ordinateur et votre AP est implémentée à l'aide d'un cryptage symétrique. Pour que le cryptage symétrique fonctionne, les deux parties (l'ordinateur et l'AP) doivent toutes deux partager une clé (une petite quantité de données confidentielles) pour crypter un flux et le décrypter ensuite.
Une façon courante de procéder consiste à utiliser une clé pré-partagée (PSK), où les deux parties sont informées de la clé avant de tenter d'établir la connexion. Voici ce que vous faites lorsque vous configurez une phrase de passe Wi-Fi: lorsque vous entrez la phrase de passe sur le routeur, puis à nouveau sur l'ordinateur, ils disposent désormais tous les deux de ces informations. Le partage de la clé n'a pas lieu sur le réseau, où elle pourrait être écoutée, mais manuellement par clavier, ce qui est généralement beaucoup plus sûr.
(La clé n'est techniquement pas la phrase secrète elle-même mais certaines données qui en sont dérivées.)
Le cryptage nécessite une clé. C'est pourquoi on vous demande une phrase secrète et pourquoi sans celle-ci, vous n'obtenez pas de cryptage. Il existe d'autres façons qu'une phrase secrète pour produire des clés, mais vous ne les trouverez pas sur votre AP.
Considérez cette situation: sans phrase secrète, la clé peut être générée (comme avec un PRNG fort) par l'AP. La clé devrait en quelque sorte être communiquée à l'ordinateur. La manière la plus simple serait de passer par la connexion sans fil elle-même (en supposant que l'AP n'a aucun autre moyen d'envoyer des données à l'ordinateur). Une fois celui-ci reçu, le trafic restant sur la connexion peut être crypté.
Le problème est que la connexion n'est pas chiffrée pendant l'envoi de la clé (si tel était le cas, le destinataire ne pourrait pas lire la clé). Un espion peut facilement récupérer la clé non chiffrée et surveiller le reste de la session comme si elle n'était pas chiffrée.
Les théoriciens diraient que puisque cela est possible, votre connexion est déjà aussi bonne que non cryptée et vous pourriez aussi bien ne pas perdre les cycles CPU à la brouiller. Je dis que bien que cette attaque ne soit efficace que si l'attaquant est là pour le début de la connexion, vous ne pouvez pas supposer que ce n'est pas le cas (tout le temps).
Il existe des moyens de contourner ce problème particulier en utilisant le chiffrement et l'authentification asymétriques (basés sur une clé publique), dans lesquels, grâce à une magie mathématique, vous êtes en mesure de chiffrer des données que personne sauf le destinataire (pas même vous!) Ne peut déchiffrer, mais il peut être compliqué à installer, et, comme la dernière fois que j'en ai acheté un, il est peu probable qu'il soit intégré à votre AP.
Mise à jour: Diffie-Hellman
Même si l'échange de clés Diffie-Hellman est utilisé, il y a toujours un problème de confiance.
Voici un bref aperçu de pourquoi:
- Sans établissement préalable de la confiance entre les parties, l'authentification n'a pas de sens.
- Sans authentification significative, DH n'est pas significatif. (Il est vulnérable à une attaque d'homme au milieu.)
- Sans DH significatif, le chiffrement basé sur un échange DH n'est pas significatif.
- Une communication sans chiffrement significatif équivaut (à peu près) à une communication sans chiffrement.
- Ainsi, un schéma de chiffrement par défaut basé sur DH n'est pas beaucoup plus sûr que pas de chiffrement sauf si la confiance a été établie en premier.
- Sans mécanisme de confiance par des tiers (comme PKI ou web of trust), l'instauration de la confiance nécessite un échange direct (en personne, par téléphone, etc. selon le niveau de paranoïa) d'informations.
- Tout mécanisme utile d'échange direct pourrait, au moins aussi facilement, être utilisé pour partager un PSK.
L'établissement de la confiance est un problème difficile à résoudre entre étrangers sans échange direct, et un tel échange direct est déjà suffisant pour partager un PSK.
Une façon d'éviter l'échange direct, en théorie, serait d'acheter un certificat SSL pour votre AP auprès d'une autorité de certification publique. Cela pourrait devenir un peu cher, et je pense que les propriétaires de points d'accès ne sont pas susceptibles de payer un supplément pour fournir une connexion Wi-Fi sécurisée à des étrangers. Un certificat auto-signé pourrait être utilisé à la place, mais cela nécessiterait que l'invité fasse confiance aveuglément à une auto-signature, ce qui la laisse ouverte au MITM, ou obtienne et installe le certificat après avoir vérifié sa signature par rapport à l'original - et cela une fois nécessitent à nouveau un échange direct.
Lorsque vous parlez de "pas de mot de passe" et de "même mot de passe", j'imagine que vous faites référence à la clé pré-partagée. Ce n'est pas réellement un mot de passe, mais utilisé comme valeur connue par la station et le point d'accès pour générer et échanger en toute sécurité (au moins à partir de sources extérieures sans la valeur connue) du matériel de clé pour le trafic chiffré. WPA/WPA2-Personal ne s'authentifie pas réellement, seulement le crypte.
WPA/WPA2-Enterprise utilise 802.1X pour s'authentifier et, si l'authentification est réussie, pour générer et échanger du matériel de clé.
Fondamentalement, pour configurer une communication cryptée, les deux parties ont besoin d'un point commun sur lequel construire le cryptage. Sur le Web (SSL/TLS), cela se fait souvent à l'aide de certificats, mais un périphérique 802.11 fonctionne sur la couche 2, ce qui exclut bon nombre de ces méthodes.
802.11 utilise les deux options pour fournir ce point commun, le PSK ou les informations de l'authentification 802.1X.
Pourquoi le WiFi ouvert n'est-il pas chiffré?
C'est la même raison pour laquelle WPA-PSK n'utilise pas l'échange de clés Diffie-Hellman/RSA .
Le premier point d'Adnan est la réponse la plus précise.
Quant à savoir pourquoi les réseaux WiFi ouverts n'ont pas de cryptage. Eh bien, ils ne le font tout simplement pas.
Il n'y a aucune raison technique. c'est probablement une raison financière et/ou bureaucratique. Et changer l'infrastructure existante n'est pas facile.
Comment savons-nous que "JFK Airport AP" est vraiment le point d'accès de l'aéroport JFK?
Notez qu'il existe une différence entre l'authentification et le cryptage. Le problème décrit est un problème d'authentification qui existe, que nous chiffrions ou non une connexion Wi-Fi. En d'autres termes: le fait que RSA ne fournit pas d'authentification n'est en rien lié à la question de savoir pourquoi RSA n'est pas mis en œuvre sur des réseaux Wi-Fi ouverts. En outre, le problème d'authentification peut être résolu à l'aide d'une méthode extrêmement simple décrite dans l'exemple suivant:
Notre futur routeur Wi-Fi avec cryptage utilise Diffie-Hellman/RSA. Le routeur a un petit écran LED qui affiche sa clé publique, ou peut-être un simple hachage de la clé publique. Le point d'accès est appelé "MyHouse".
Je voudrais connecter mon téléphone à "MyHouse", mais il y a un autre AP avec exactement le même nom, tout ce que j'ai à faire est de regarder le moniteur de mon routeur et de comparer la chaîne à la chaîne affichée sur mon téléphone, de cette façon, facile l'authentification est réalisée. Les aéroports et les lieux publics peuvent utiliser des techniques similaires en affichant la clé publique/le hachage sur de grands écrans ou sur des autocollants à faible coût.
Note latérale: La LED n'est qu'un exemple, de nombreuses autres méthodes sont disponibles.
Certains routeurs peuvent-ils être configurés pour autoriser l'accès public sans mot de passe, mais> chiffrer les connexions des utilisateurs pour empêcher les attaques de style Firesheep?
Oui, cela peut être configuré, mais ce ne serait pas au niveau du routeur. Et celui qui se connecte devrait prendre des mesures supplémentaires.
Solution 1. Proxy Web HTTPS
Une technique extrêmement simple que l'on pourrait utiliser immédiatement est la navigation sur le Web à l'aide d'un proxy Web crypté HTTPS, tel que HideMyAss . De cette façon, on utilise la cryptographie à clé publique, mais cela se fait au-dessus de la couche TCP.
Solution 2. un serveur VPN LAN ou un serveur tunnel SSH
Une approche similaire peut être utilisée sur le réseau local sans dépendre de sites externes: Utilisez un serveur VPN local/serveur Tunnel SSH. Les données circuleraient de cette façon:
Périphérique réseau (disons, mon téléphone)> AP> Périphérique réseau (serveur tunnel VPN/SSH)> AP> Internet. (# flow1)
Le tunnel VPN/SSH agit comme une extension de l'AP, si nous les encapsulons mentalement, nous obtiendrions:
Périphérique réseau (Mon téléphone)> AP crypté> Destination. (# flow2)
Solution 2. Remarques importantes!
Vous DEVEZ utiliser une connexion filaire entre le tunnel VPN/SSH et l'AP si vous utilisez la solution LAN, voir la fin de ma réponse.
Si vous souhaitez l'implémenter pratiquement, vous pouvez utiliser une petite puissance toujours faible sur un ordinateur tel qu'un RaspberryPi comme serveur de tunnel SSH, je l'ai essayé et je ne vois aucune latence notable.
Solution 3. Serveur de tunnel VPN/SSH standard
On pourrait utiliser un VPN qui n'est pas sur le LAN, alors nous aurions:
Périphérique réseau (Mon téléphone)> AP> VPN> Destination. (# flow3)
Dans les 3 cas, les données sont entièrement cryptées à l'aide de TLS/SSL/Quel que soit votre VPN/SSH crypté.
Si vous utilisez la solution LAN VPN/SSH, le serveur doit être câblé , sinon le trafic qui est transmis par le serveur VPN/SSH du client vers la destination sera envoyée non chiffrée à l'AP.
Plus d'informations sur la solution LAN
Si vous utilisez une connexion sans fil sur un réseau WiFi ouvert avec une solution de serveur de tunnel LAN VPN/SSH, c'est ainsi que le trafic circule. Il s'agit d'une extension de "flow1", dans laquelle le fait que les données soient chiffrées ou non est ajouté au flux:
Périphérique réseau> données cryptées> AP> données cryptées> serveur VPN/SSH> données non cryptées > AP> Internet
Pour cette raison, nous devons utiliser un câble câblé entre le serveur VPN/SSH et AP, de cette façon, les données non chiffrées ne sont jamais envoyées par voie aérienne.
Je soupçonne que la réponse a à voir avec "l'apatridie" du routeur WIFI. Les paquets entrants et sortants sont traités de manière uniforme. Si une sorte de chiffrement était négocié sur une base par connexion, le routeur devrait maintenir l'état de chaque partenaire de communication. Cela briserait le modèle de "couche"; que les paquets sont traités uniformément et que les couches supérieures traitent de choses comme le chiffrement et la continuité.