Die Frage (für die meisten Menschen) ist ein Oxymoron. Per Definition werden die Leute denken, dass "offenes WiFi" "unverschlüsseltes WiFi" bedeutet. Für mich scheinen Sie zu fragen "Warum haben die Leute, die 1997 den Standard 802.11 geschrieben haben, die Entscheidungen getroffen, die haben sie es getan? "

Die kurze Antwort - wir können es nur herausfinden, indem wir sie fragen (oder sehen, ob im Internet Diskussionsdokumente herumschwirren).

Wir können es jedoch Besprechen Sie den Firesheep-Teil der Frage. Ein "Firesheep" -Angriff ist eine bestimmte Art von Angriff, bei dem Cookies, die einen Benutzer bei einer Site authentifizieren, von einem Angreifer kopiert werden.

Die einzige Voraussetzung ist, dass die Cookies sein können Vom Angreifer erhalten - und daher WiFi-Netzwerke, die WEP, WPA oder WPA2 mit einem einzigen vorinstallierten Schlüssel verwenden, sind anfällig, wenn der Angreifer über den Schlüssel verfügt . Und natürlich Viele kleine Unternehmen bieten WLAN-Zugang mit einem einzigen Schlüssel.

"bessere" Zugangspunkte sind eine teure Möglichkeit, dieses Problem zu beheben, und machen Benutzer weiterhin anfällig für die oben genannten Angriffe Szenario (in dem der Angreifer eine ARP-Vergiftung sowie einen Man-in-the-Middle -Angriff gegen reine HTTP-Sites verwenden kann).

Daher soweit Die beste und nützlichste Lösung wäre die weit verbreitete Implementierung von HTTPS ( wie vom Entwickler von Firesheep, Eric Butler, empfohlen)

Firesheep hat nichts mit der WiFi-Verschlüsselung zu tun. Wenn Sie und ich beide eine verschlüsselte WiFi-Verbindung hätten, könnte ich Ihre Daten trotzdem feuern.

Was Firesheep tut, geschieht auf Routerebene. Es fängt die Wellen in der Luft nicht ab (na ja, nicht genau).

Grundsätzlich führt es einen ARP-Spoofing -Angriff aus. Diese Art von Angriff kann auch in einem LAN-Netzwerk ausgeführt werden. Dabei werden die Router-Lügen über die MAC-Adresse gespeist, die einer bestimmten IP entspricht. Wenn ein Router ein Paket an eine bestimmte IP verteilen möchte, muss er herausfinden, wem diese IP gehört. Wenn sich diese Daten nicht im Cache befinden, wird eine Nachricht gesendet, in der Sie nach diesen Details gefragt werden. Jeder im Subnetz kann auf die Sendung antworten und sagen, dass die IP ihnen gehört, auch wenn dies nicht der Fall ist. Auf diese Weise kann sich ein Angreifer direkt zwischen dem Router und dem Opfer im Kommunikationskanal befinden.

Um es klar auszudrücken: Dies ist ein Problem mit TCP / IP (dem Protokoll, das das Netzwerk steuert). Nicht mit WiFi.

Die anderen Antworten haben bereits erklärt, dass Angriffe im Firesheep-Stil (im Grunde MitM, obwohl ARP-Spoofing) nichts mit WiFi selbst zu tun haben. Dies ist ein Link-Layer -Problem.

Warum offene WiFi-Netzwerke nicht verschlüsselt sind. Nun, sie tun es einfach nicht. Ich weiß nicht wirklich, warum sie sich dagegen entschieden haben, ich kann nur spekulieren. Ein sehr offensichtlicher Grund sind MitM-Angriffe, da sich jeder als Access Point (AP) ausgeben und die verschlüsselte Verbindung mit den Opfern aushandeln kann. Dies führt zu einem PKI -Problem, falls AP-Besitzer vertrauenswürdige Zertifikate für ihre Zugriffspunkte erwerben. Aber das macht den ganzen Zweck eines Open Wifi-Netzwerks zunichte, denn dann müssten Sie die Identität des AP überprüfen.

Woher wissen wir, dass "JFK Airport AP" wirklich der Zugangspunkt von JFK ist Flughafen? Sollten wir Zertifikate für Zugangspunkte mit dem Namen "JFK AP" ausstellen? Würde das zu Social-Engineering-Angriffen führen? Muss ich meine eigenen Zertifikate erstellen und dann meine Freunde bitten, ihnen zu vertrauen, wenn sie eine Verbindung zu meinem Netzwerk herstellen? Jetzt könnte man natürlich argumentieren, dass wir das Trust-on-First-Use-Modell verwenden können, aber das funktioniert nicht WiFi-Netzwerke in Parks, Flughäfen oder auf der Straße.

Es gibt einige Vorschläge zur Lösung des Problems, wie ein Vorschlag von Studenten der Ohio State University, den sie Dummy nennen Authentifizierung

Unsere Lösung verwendet die vorhandenen Verschlüsselungsalgorithmen für symmetrische Schlüssel, z. B. TKIP und AES, die bereits in den Produkten WPA und 802.11i verwendet werden, um drahtlose Frames vor Spoofing und Abhören zu schützen. Um die vorhandenen Verschlüsselungsalgorithmen verwenden zu können, werden offensichtlich Verschlüsselungsschlüssel benötigt. In diesem Abschnitt schlagen wir zunächst einen neuen Algorithmus zur Einrichtung eines Dummy-Authentifizierungsschlüssels vor. Dann verwenden wir den festgelegten Sitzungsschlüssel, um drahtlose Frames zu schützen.

Was ich wirklich mag. Wenn Sie ein wenig darüber nachdenken, werden Sie feststellen, dass das Sniffing-Problem und AP-Identitätswechselprobleme (wie beim ARP-Spoofing) bei Verwendung von CA-ausgestellten Zertifikaten gelöst wird.

Wir gehen davon aus, dass jeder AP ein öffentlich-privates Schlüsselpaar hat, das als pk und sk bezeichnet wird, z. B. RSA-Schlüssel. Der öffentliche Schlüssel ist in einem CA-signierten Zertifikat oder einem selbstsignierten Zertifikat enthalten.

Dazu müssten natürlich alle vorhandenen WiFi-Zugangspunkte aktualisiert und Betriebssysteme gepatcht werden. Keine leichte Sache.

Sie haben Recht, dass es sich nicht um dasselbe Problem handelt: Die Kennwortauthentifizierung und die symmetrische Verschlüsselung sind völlig unabhängige Konzepte, die jeweils ohne das andere implementiert werden können. Ein Kennwort ist jedoch eine von mehreren Möglichkeiten, um den für den Betrieb der Verschlüsselung erforderlichen Schlüssel zu erstellen.

Eine verschlüsselte Verbindung wie die zwischen Ihrem Computer und Ihrem AP wird mithilfe einer symmetrischen Verschlüsselung implementiert. Damit die symmetrische Verschlüsselung funktioniert, müssen beide Parteien (der Computer und der AP) einen Schlüssel (eine kleine Menge vertraulicher Daten) gemeinsam nutzen, um einen Stream zu verschlüsseln und anschließend zu entschlüsseln.

Eine gängige Methode hierfür verwendet einen Pre-Shared Key (PSK), bei dem beide Parteien vor dem Versuch, die Verbindung herzustellen, auf den Schlüssel aufmerksam gemacht werden. Dies tun Sie, wenn Sie eine Wi-Fi-Passphrase einrichten: Wenn Sie die Passphrase auf dem Router und dann wieder auf dem Computer eingeben, verfügen beide nun über diese Informationen. Die gemeinsame Nutzung des Schlüssels erfolgt nicht über das Netzwerk, wo er abgehört werden könnte, sondern manuell über die Tastatur, was in der Regel sehr viel sicherer ist.

(Der Schlüssel ist technisch gesehen nicht die Passphrase selbst, sondern einige daraus abgeleitete Daten.)

Für die Verschlüsselung ist ein Schlüssel erforderlich. Aus diesem Grund werden Sie nach einer Passphrase gefragt, und ohne eine erhalten Sie keine Verschlüsselung. Es gibt andere Möglichkeiten als eine Passphrase, um Schlüssel zu erstellen, aber Sie werden sie nicht auf Ihrem AP finden.

Betrachten Sie diese Situation: Ohne eine Passphrase kann der Schlüssel generiert werden (z. B. mit einem starken PRNG). von der AP. Der Schlüssel müsste irgendwie an den Computer übermittelt werden. Der einfache Weg wäre über die drahtlose Verbindung selbst (vorausgesetzt, der AP hat keine andere Möglichkeit, Daten an den Computer zu senden). Sobald dies empfangen wurde, kann der verbleibende Datenverkehr auf der Verbindung verschlüsselt werden.

Das Problem ist, dass die Verbindung nicht verschlüsselt wird, während der Schlüssel gesendet wird (wenn dies der Fall wäre, könnte der Empfänger den Schlüssel nicht lesen). Ein Lauscher kann den unverschlüsselten Schlüssel leicht abrufen und den Rest der Sitzung überwachen, als wäre er nicht verschlüsselt.

Die Theoretiker würden sagen, da dies möglich ist, ist Ihre Verbindung bereits so gut wie unverschlüsselt und Sie könnte genauso gut nicht die CPU-Zyklen verschwenden, die es verschlüsseln. Ich sage, dass dieser Angriff zwar nicht effektiv wäre, wenn der Angreifer nicht zu Beginn der Verbindung da wäre, Sie jedoch nicht sicher davon ausgehen können, dass dies nicht immer der Fall ist.

Dort Es gibt Möglichkeiten, um dieses spezielle Problem mithilfe der asymmetrischen (auf öffentlichen Schlüsseln basierenden) Verschlüsselung und Authentifizierung zu umgehen, bei der Sie mithilfe mathematischer Magie Daten verschlüsseln können, die nur der Empfänger (nicht einmal Sie!) entschlüsseln kann, die jedoch kompliziert sein können Die Einrichtung ist wahrscheinlich keine integrierte Funktion Ihres AP.

Update: Diffie-Hellman

Auch wenn Wenn der Diffie-Hellman-Schlüsselaustausch verwendet wird, gibt es immer noch ein Vertrauensproblem.

Hier ein kurzer Überblick über die Gründe:

• Ohne vorherige Vertrauensbildung zwischen den Parteien Authentifizierung ist nicht aussagekräftig.
• Ohne aussagekräftige Authentifizierung ist DH nicht aussagekräftig. (Es ist anfällig für einen Man-in-the-Middle-Angriff.)
• Ohne aussagekräftige DH ist eine Verschlüsselung basierend auf einem DH-Austausch nicht sinnvoll.
• Kommunikation ohne sinnvolle Verschlüsselung ist ( ungefähr) gleichbedeutend mit Kommunikation ohne Verschlüsselung.
• Daher ist ein DH-basiertes Standardverschlüsselungsschema nicht wesentlich sicherer als keine Verschlüsselung, es sei denn, zuerst wurde Vertrauen hergestellt.
• Ohne Mechanismus Für die Vertrauensbildung durch Dritte (wie PKI oder Web of Trust) erfordert die Vertrauensbildung einen direkten Informationsaustausch (persönlich, telefonisch usw. je nach Paranoia-Level).

Vertrauensbildung ist ein Problem, das ohne direkten Austausch zwischen Fremden nur schwer zu lösen ist Ein solcher direkter Austausch reicht bereits aus, um eine PSK gemeinsam zu nutzen.

Eine Möglichkeit, den direkten Austausch zu vermeiden, besteht theoretisch darin, ein SSL-Zertifikat für Ihren AP von einer öffentlichen Zertifizierungsstelle zu kaufen. Dies könnte etwas teuer werden, und ich denke, dass AP-Besitzer nicht so wahrscheinlich extra bezahlen, um Fremden sicheres WLAN zur Verfügung zu stellen. Stattdessen könnte ein selbstsigniertes Zertifikat verwendet werden. Dies würde jedoch erfordern, dass der Gast entweder blind einer Selbstsignatur vertraut, die sie für MITM offen lässt, oder das Zertifikat abruft und installiert, nachdem seine Signatur mit dem Original verglichen wurde - und dies einmal erfordern erneut einen direkten Austausch.

Wenn Sie von "kein Passwort" und "dasselbe Passwort" sprechen, stellen Sie sich vor, Sie beziehen sich auf den vorinstallierten Schlüssel. Dies ist eigentlich kein Passwort, sondern wird von der Station und dem AP als bekannter Wert verwendet, um Schlüsselmaterial für den verschlüsselten Verkehr zu generieren und sicher (zumindest von externen Quellen ohne den bekannten Wert) auszutauschen. WPA / WPA2-Personal authentifiziert sich nicht, sondern verschlüsselt nur.

WPA / WPA2-Enterprise verwendet 802.1X zur Authentifizierung und bei erfolgreicher Authentifizierung zum Generieren und Austauschen von Schlüsselmaterial.

Um eine verschlüsselte Kommunikation einzurichten, benötigen beide Seiten einen gemeinsamen Punkt, auf dem die Verschlüsselung aufgebaut werden kann. Im Web (SSL / TLS) erfolgt dies häufig mithilfe von Zertifikaten. Ein 802.11-Gerät arbeitet jedoch auf Schicht 2, was viele dieser Methoden ausschließt.

802.11 verwendet die beiden Optionen, um dies bereitzustellen Gemeinsamer Punkt, entweder das PSK oder Informationen aus der 802.1X-Authentifizierung.

Warum ist offenes WLAN nicht verschlüsselt?

Aus demselben Grund verwendet WPA-PSK keinen Diffie-Hellman / RSA-Schlüsselaustausch

Adnans erster Punkt ist die genaueste Antwort.

Warum offene WiFi-Netzwerke nicht verschlüsselt sind. Nun, das tun sie einfach nicht.

Es gibt keinen technischen Grund. Es ist wahrscheinlich ein finanzieller und / oder bürokratischer Grund. Das Ändern der vorhandenen Infrastruktur ist nicht einfach.

Woher wissen wir, dass "JFK Airport AP" wirklich der Zugangspunkt des JFK-Flughafens ist?

Beachten Sie, dass es einen Unterschied zwischen Authentifizierung und Verschlüsselung gibt . Das beschriebene Problem ist ein Authentifizierungsproblem, das unabhängig davon besteht, ob wir eine Wi-Fi-Verbindung verschlüsseln oder nicht. Mit anderen Worten: Die Tatsache, dass RSA keine Authentifizierung bereitstellt, hängt in keiner Weise mit der Frage zusammen, warum RSA nicht in offenen Wi-Fi-Netzwerken implementiert wird. Das Authentifizierungsproblem kann auch mit einer äußerst einfachen Methode gelöst werden, die im folgenden Beispiel beschrieben wird:

Unser zukünftiger, verschlüsselungsfähiger WLAN-Router verwendet Diffie-Hellman / RSA. Der Router verfügt über eine kleine LED-Anzeige, die seinen öffentlichen Schlüssel oder möglicherweise einen einfachen Hash des öffentlichen Schlüssels anzeigt. Der Zugangspunkt heißt "MyHouse".

Ich möchte mein Telefon mit "MyHouse" verbinden, aber es gibt einen anderen AP mit genau demselben Namen. Ich muss nur auf den Monitor meines Routers schauen und vergleichen Sie die Zeichenfolge mit der auf meinem Telefon angezeigten Zeichenfolge. Auf diese Weise wird eine einfache Authentifizierung erreicht. Flughäfen und öffentliche Orte können ähnliche Techniken anwenden, indem sie den öffentlichen Schlüssel / Hash auf großen Bildschirmen oder auf einigen kostengünstigen Aufklebern anzeigen.

Randnotiz: Die LED ist nur ein Beispiel, es stehen viele andere Methoden zur Verfügung.

Können einige Router so konfiguriert werden, dass sie den öffentlichen Zugriff ermöglichen Noch kein Passwort,> die Benutzerverbindungen verschlüsseln, um Angriffe im Firesheep-Stil zu verhindern?

Ja, das kann konfiguriert werden, aber nicht auf Router-Ebene. Und derjenige, der eine Verbindung herstellt, müsste einige zusätzliche Schritte ausführen.

Lösung 1. HTTPS-Webproxy

Eine äußerst einfache Technik, die man sofort anwenden kann, ist das Durchsuchen des Web mit einem HTTPS-verschlüsselten Webproxy wie HideMyAss. Auf diese Weise wird eine Kryptografie mit öffentlichem Schlüssel verwendet, die jedoch über der TCP-Schicht erfolgt.

Lösung 2. Ein LAN-VPN-Server oder ein SSH-Tunnelserver

Ein ähnlicher Ansatz kann im lokalen Netzwerk verwendet werden, ohne von externen Standorten abhängig zu sein: Verwenden Sie einen lokalen VPN-Server / SSH-Tunnel-Server. Die Daten würden folgendermaßen fließen:

Netzwerkgerät (z. B. mein Telefon)> AP> Netzwerkgerät (VPN / SSH-Tunnelserver)> AP> Internet. (# flow1)

Der VPN / SSH-Tunnel fungiert als Erweiterung des AP. Wenn wir diese mental einkapseln, erhalten wir:

Netzwerkgerät ( Mein Telefon)> Verschlüsselter AP> Ziel. (# flow2)

Lösung 2. Wichtige Hinweise!

• Sie MÜSSEN Verwenden Sie eine Kabelverbindung zwischen dem VPN / SSH-Tunnel und dem APif mithilfe der LAN-Lösung. Weitere Informationen finden Sie am Ende meiner Antwort.

• Wenn Sie dies praktisch implementieren möchten, können Sie dies tun Verwenden Sie einen winzigen Computer mit geringem Stromverbrauch, z. B. einen RaspberryPi, als SSH-Tunnelserver. Versuchen Sie es und ich sehe keine merkliche Latenz.

Lösung 3. Normaler VPN / SSH-Tunnelserver

Man könnte ein VPN verwenden, das sich nicht im LAN befindet, dann erhalten wir:

Netzwerk Gerät (Mein Telefon)> AP> VPN> Ziel. (# flow3)

In allen drei Fällen werden die Daten vollständig mit TLS / SSL / verschlüsselt, mit dem Ihr VPN / SSH verschlüsselt ist.

Bei Verwendung der LAN-VPN / SSH-Lösung muss der Server verkabelt sein , andernfalls wird der vom VPN / SSH-Server vom Client zum Ziel weitergeleitete Datenverkehr unverschlüsselt gesendet an den AP.

Weitere Informationen zur LAN-Lösung

Wenn Sie eine drahtlose Verbindung in einem offenen WLAN mit einer LAN-VPN / SSH-Tunnelserverlösung verwenden, fließt der Datenverkehr auf diese Weise. Dies ist eine Erweiterung von "flow1", bei der dem Fluss hinzugefügt wird, ob die Daten verschlüsselt sind oder nicht:

Netzwerkgerät> verschlüsselte Daten > AP> verschlüsselte Daten VPN / SSH-Server> unverschlüsselte Daten > AP> Internet

Aus diesem Grund müssen wir ein Kabel verwenden Auf diese Weise werden die unverschlüsselten Daten zwischen dem VPN / SSH-Server und dem AP niemals über die Luft gesendet.

Ich vermute, die Antwort hat mit der "Staatenlosigkeit" des WIFI-Routers zu tun. Eingehende und ausgehende Pakete werden einheitlich behandelt. Wenn eine Art von Verschlüsselung pro Verbindung ausgehandelt würde, müsste der Router den Status für jeden Kommunikationspartner beibehalten. Dies würde das "Layer" -Modell zerstören. dass Pakete einheitlich behandelt werden und höhere Schichten sich mit Dingen wie Verschlüsselung und Kontinuität befassen.

Heutzutage gibt es tatsächlich einen Ansatz zum Verschlüsseln von Verbindungen zum Öffnen von WLAN-Hotspots mithilfe von "Opportunistic Wireless Encryption". OWE ist in RFC 8110 angegeben.

Ich weiß jedoch nicht, welche Clients oder Hotspots diesen Standard tatsächlich unterstützen.

Ich bin kein Sicherheitsexperte und habe nur grundlegende Kenntnisse der Kryptografie, aber ich denke, dass Sie absolut Recht haben und die Verbindung zu WLAN mit DH verschlüsselt werden sollte, um zumindest vor Abhören zu schützen. Dies kann nicht vor MitM schützen, aber dieser Angriff ist schwieriger durchzuführen. Insbesondere kann dies durch das Vertrauen in die erste Verwendung erheblich verhindert werden.

Und tatsächlich können wir noch weiter gehen und PKI wie für HTTPS implementieren. Zum Beispiel bedient mein Router auch meine Homepage und hat eine eigene Domain und ein von CA signiertes HTTPS-Zertifikat. Es wäre also großartig, wenn in der Liste der drahtlosen Netzwerke ein grünes Vorhängeschloss wie im Browser angezeigt würde. Für die großen öffentlichen Zugangspunkte wie auf Flughäfen könnte dies auch eine kostengünstige Lösung sein.

Ich habe auch keine Ahnung, warum ich nicht ein normales TLS / SSH anstelle einiger CRACKed-Algorithmen verwenden soll.

Das ist eine große Verantwortungslosigkeit, dass dies nicht so lange implementiert wurde und Milliarden von Benutzern jetzt verwundbar sind, auch ohne dies zu wissen.

Vor kurzem wurde jedoch ein WPA3 veröffentlicht, das Perfect Forward Secrecy enthält und von OpenWrt unterstützt wird Hier ist ein interessanter Artikel mit ersten Eindrücken darüber https://gist.github.com/est31/d92d17acbb4ea152296f9b38764cd791

Hoffe, dies löst das Problem, aber wer weiß - Vielleicht hat es auch einige Schwachstellen.