wireshark, wlan

[absolute beginner]

hallo,

einige Fragen zu wireshark.

Ich möchte an meinem laptop das wlan-interface mit wireshark überwachen. Ich befinde mich in einem wpa2-verschlüsselten wlan-Netzwerk. Wenn ich die Option "follow TCP-Stream" nutze, sehe ich den ganzen zusammenhängenden Datenverkehr (z.b. wenn ich eine Website aufrufe). Die Http-Header von Request und Response sehe ich jeweils im Klartext, den Response-Content scheinbar verschlüsselt. Scheinbar deshalb, weil ich es nicht recht zu deuten vermag. Ich bin, wie gesagt, ein absoluter Anfänger in Netzwerkfragen.

meine Fragen:

a) warum sind die HTTP-Header nicht verschlüsselt? Sind bei wlan nicht per se immer ALLE Daten verschlüsselt?
b) wie kann ich die Daten entschlüsselt sehen? Den Sicherheitskey habe ich ja, ist ja mein Wlan-Netzwerk.
c) Ich würde gerne den Datenverkehr anderer Nutzer in diesem Wlan-Netzwerk sehen. Muss dazu monitor mode aktiviert sein? Leider geht das bei mir nicht, ich kann diese Option nicht anwählen, obwohl sie nicht ausgegraut ist.

wäre cool, wenn mir jemand helfen könnte.

danke, ab

[Der Martin]

Hi,

Ich möchte an meinem laptop das wlan-interface mit wireshark überwachen. Ich befinde mich in einem wpa2-verschlüsselten wlan-Netzwerk.

auf welchem Rechner läuft Wireshark? Auf demselben Laptop, oder auf einem anderen Rechner, der ebenfalls am WLAN "teilnimmt"?

Wenn ich die Option "follow TCP-Stream" nutze, sehe ich den ganzen zusammenhängenden Datenverkehr (z.b. wenn ich eine Website aufrufe). Die Http-Header von Request und Response sehe ich jeweils im Klartext, den Response-Content scheinbar verschlüsselt. Scheinbar deshalb, weil ich es nicht recht zu deuten vermag. Ich bin, wie gesagt, ein absoluter Anfänger in Netzwerkfragen.

Das ist aber eigenartig. Zumindest wenn du normales HTTP verwendest, also keine SSL-Verbindung zum Server, sollte die Kommunikation komplett unverschlüsselt sein. Textbasierte Ressourcen wie HTML, Stylesheets oder Javascript solltest du also im Klartext mitlesen können.
Oder meinst du mit "verschlüsselt" den binären Datenwust, aus dem Bilder bestehen?

a) warum sind die HTTP-Header nicht verschlüsselt? Sind bei wlan nicht per se immer ALLE Daten verschlüsselt?

Die WLAN-Verschlüsselung gilt ja nur für die Funkstrecke von einem WLAN-Adapter zum anderen. Anders gesagt: Wireshark greift die Daten ja sozusagen auf der CPU-Seite des WLAN-Adapters ab, wo die WPA2-Verschlüsselung noch nicht (Sendedaten) bzw. schon nicht mehr (Empfangsseite) vorliegt.
Stell dir vor, du ziehst grundsätzlich Schuhe (WPA2) an, wenn du nach draußen gehst, und ziehst sie wieder aus, wenn du heimkommst. In der Öffentlichkeit sehen die Leute dich also immer mit Schuhen (verschlüsselt), aber ein Beobachter innerhalb deiner Wohnung könnte dich trotzdem ohne Schuhe sehen.

Selbst wenn Wireshark auf einem anderen Rechner läuft und einfach passiv mitlauscht, würde er Klartext sehen, da die Daten auch in diesem Fall vom Netzwerkadapter (oder dessen Treiber) wieder entschlüsselt sind. Vorausgesetzt, alle WLAN-Teilnehmer haben den richtigen WPA2-Key.

b) wie kann ich die Daten entschlüsselt sehen? Den Sicherheitskey habe ich ja, ist ja mein Wlan-Netzwerk.

Das ist eine gute Frage, aber sie müsste eigentlich andersrum lauten: Warum siehst du verschlüsselte Daten?

c) Ich würde gerne den Datenverkehr anderer Nutzer in diesem Wlan-Netzwerk sehen. Muss dazu monitor mode aktiviert sein?

Vermutlich ja, ich habe Wireshark aber noch nie im WLAN benutzt.

Leider geht das bei mir nicht, ich kann diese Option nicht anwählen, obwohl sie nicht ausgegraut ist.

Dann bin ich überfragt.
Bedenke aber, dass es rechtlich problematisch sein kann, wenn du den Netzwerkverkehr anderer Teilnehmer ohne deren Wissen mitliest. Das ist genau der Grund, warum Wireshark umstritten ist und oft als Hacker-Tool bezeichnet wird.

So long,
 Martin

[absolute beginner]

Hallo Martin,

danke dir für deine Hilfe. Ich kopiere dir mal alles hier rein, was ich von wireshark erhalte, wenn ich "follow tcp-stream" nutze. ich rufe auf dem Host example.com (geändert) die Datei test.php auf, die nur das Wort "maus" ausgibt.

  
GET /test.php HTTP/1.1  
Host: example.com  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3  
Accept-Encoding: gzip, deflate  
Connection: keep-alive  
  
HTTP/1.1 200 OK  
Date: Sun, 19 May 2013 17:19:31 GMT  
Server: Apache  
X-Powered-By: PHP/5.2.12-nmm4  
Vary: Accept-Encoding  
Content-Encoding: gzip  
Content-Length: 24  
Keep-Alive: timeout=1, max=100  
Connection: Keep-Alive  
Content-Type: text/html; charset=UTF-8  
  
...........M,-....Y:....  
  

...........M,-....Y:.... soll wohl "maus" sein.... ich dachte, das wäre verschlüsselt?

danke und gruß
ab

[Der Martin]

Hi,

danke dir für deine Hilfe. Ich kopiere dir mal alles hier rein, was ich von wireshark erhalte, wenn ich "follow tcp-stream" nutze. ich rufe auf dem Host example.com (geändert) die Datei test.php auf, die nur das Wort "maus" ausgibt.

normalerweise müsste ich jetzt mäkeln, dass du die eigentlich wichtigen Informationen (nämlich den Hex-Dump der empfangenen Daten) weggelassen hast und stattdessen nur die unvollständige ASCII-Ersatzdarstellung zeigst. Das mach ich aber nicht, denn ich sehe etwas im HTTP-Response-Header, das das Problem vollständig erklärt.

GET /test.php HTTP/1.1

Host: example.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Sun, 19 May 2013 17:19:31 GMT
Server: Apache
X-Powered-By: PHP/5.2.12-nmm4
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 24
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

  
Entscheidend ist der Response-Header "Content-Encoding: gzip". Da dein Browser im Request-Header angegeben hat, dass er die Antwortdaten gegebenenfalls auch komprimiert akzeptiert ("Accept-Encoding: gzip, deflate"), hat der Server das wörtlich genommen und sich entschlossen, die Antwort gzip-komprimiert zu schicken. Natürlich nur den Datenblock, der Header muss in jedem Fall Klartext bleiben.  
Es handelt sich also hier nicht um verschlüsselte Daten im üblichen Sinn, sondern komprimierte. Und da der Browser gesagt hat, "Kannst mir ruhig gezippte Daten schicken", wird er sie auch intern selbst ent-zippen.  
  
So long,  
 Martin  

-- 
Ich verdanke meinen Eltern so viel - besonders meiner Mutter und meinem Vater.  
  (Dakota Fanning, US-Nachwuchsschauspielerin)  
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(

[absolute beginner]

Hi Martin,

normalerweise müsste ich jetzt mäkeln, dass du die eigentlich wichtigen Informationen (nämlich den Hex-Dump der empfangenen Daten) weggelassen hast und stattdessen nur die unvollständige ASCII-Ersatzdarstellung zeigst.

was würde denn dort noch mehr zu finden sein? Bzw, warum ist die Ascii-Darstellung nur ein unvollständiger Ersatz?

Entscheidend ist der Response-Header "Content-Encoding: gzip". Da dein Browser im Request-Header angegeben hat, dass er die Antwortdaten gegebenenfalls auch komprimiert akzeptiert ("Accept-Encoding: gzip, deflate"), hat der Server das wörtlich genommen und sich entschlossen, die Antwort gzip-komprimiert zu schicken. Natürlich nur den Datenblock, der Header muss in jedem Fall Klartext bleiben.
Es handelt sich also hier nicht um verschlüsselte Daten im üblichen Sinn, sondern komprimierte. Und da der Browser gesagt hat, "Kannst mir ruhig gezippte Daten schicken", wird er sie auch intern selbst ent-zippen.

ah, irgendwie dachte ich mir das schon. Danke! Gibts einen Weg, dass in Wireshark zu konfigurieren, dass die Komprimierung berücksichtigt wird? Aber erstmal reicht mir das schon!

danke und schönen Sonntag noch
ab

[Der Martin]

n'Abend,

normalerweise müsste ich jetzt mäkeln, dass du die eigentlich wichtigen Informationen (nämlich den Hex-Dump der empfangenen Daten) weggelassen hast und stattdessen nur die unvollständige ASCII-Ersatzdarstellung zeigst.
was würde denn dort noch mehr zu finden sein? Bzw, warum ist die Ascii-Darstellung nur ein unvollständiger Ersatz?

sie ist deshalb unvollständig, weil nur die Byte-Werte im Bereich 0x20..7F wiedergegeben und alle Werte von 0x00..1F sowie 0x80..FF nur als Punkt dargestellt werden. Oder andersrum: Da, wo ein Punkt angezeigt wird, könnte im Original-Datenblock der Wert 0x2E stehen (das ist der ASCII-Code für den Punkt), aber auch einer von 160 möglichen anderen Werten.
Nimm mal einen Zeitungsartikel und ersetze alle Konsonanten durch 'n'. Das wäre in etwa dasselbe.

Gibts einen Weg, dass in Wireshark zu konfigurieren, dass die Komprimierung berücksichtigt wird?

Nicht dass ich wüsste. Aber ich habe auch noch nicht danach gesucht. ;-)

Schönen Abend noch,
 Martin

[Matthias Apsel]

On nan noo nen nyeenn, nen nannin!

n'anenn,

nonnanenneine nünnne inn nennn nänenn, nann nu nie einennninn ninnninen innonnanionen (nänninn nen nen-nunn nen ennnannenen nanen) nennenannen nann unn nnannnennen nun nie unnonnnnännine annii-ennannnannnennunn neinnn.
nan nünne nenn nonn nonn nenn nu ninnen nein? nnn, nanun inn nie annii-nannnennunn nun ein unnonnnnänninen ennann?

nie inn nennann unnonnnnännin, nein nun nie nnne-nenne in neneinn 0n20..7n nienennenenen unn anne nenne non 0n00..1n nonie 0n80..nn nun ann nunnn nannennennn nennen. onen annennnun: na, no ein nunnn anneneinn ninn, nönnne in onininan-nanennnonn nen nenn 0n2e nnenen (nan inn nen annii-none nün nen nunnn), anen aunn einen non 160 nönninnen annenen nennen.
ninn nan einen neinunnnanninen unn ennenne anne nonnonannen nunnn 'n'. nan näne in enna nannenne.

ninnn einen nen, nann in ninennann nu nonninunienen, nann nie nonnninienunn nenünnninnninn ninn?

ninnn nann inn nünnne. anen inn nane aunn nonn ninnn nanann nenunnn. ;-)

nnnönen anenn nonn,
nannin

--
onnnunn inn, nenn nan ennan ninnen, nan nan nan ninnn nunnn.
nennnone: no:) nn:{ nn:| nn:< n4:( ie:| no:| na:) ne:] nu:) nn:{ nn:) nn:µ nn:(

nannnian

[Jörg Reinholz]

Nun ja. Mit etwas Mühe kann man den komprimierten Teil extrahieren und dekomprimieren. Deutlich weniger Mühe dürfte es machen, gar nicht erst komprimierte Daten anzufordern.

Anleitung für Firefox: (Aber bitte erst die gesamte Antwort lesen!)

1.) öffne about:config (akzeptiere das Ende der Gewährleistung)
2.) Suche nach network.http.accept-encoding
3.) Lösche die Einträge gzip, deflate

Alternativ kannst Du einen anderen User-Agent benutzen, der gzip und/oder deflate nicht akzeptiert. Damit verbinden sich aber funktionelle Einschränkungen

Noch besser ist es, wenn du Firefox wie folgt startest:

firefox -ProfileManager -new-instance

Dann lege ein neues Profil an, vergib einen Name z.B. "nocompress", starte mit diesem Profil, lösche in diesem Profil die Einstellung wie oben gezeigt. Beende Firefox.

Rufe firefox ganz normal auf. Wähle das Profil "default" und setze den Haken bei "nicht mehr fragen"

Rufe für den Test firefox -P nocompress -new-instance auf. Baue Dir dafür auch eine eigene Verknüpfung, die Du passend benennst. In diesem Profil musst Du ggf. alle Erweiterungen wieder installieren (soweit Du das willst). Es ist für das Entwickeln ohnehin nicht schlecht einen Firefox ohne Addblocker etc. zu haben.

Jörg Reinholz

[dedlfix]

Tach!

Nun ja. Mit etwas Mühe kann man den komprimierten Teil extrahieren und dekomprimieren.

Die Mühe beschränkt sich darauf, ein Häkchen zu setzen.

dedlfix.

[absolute beginner]

Hi,

Nun ja. Mit etwas Mühe kann man den komprimierten Teil extrahieren und dekomprimieren.

Die Mühe beschränkt sich darauf, ein Häkchen zu setzen.

top! Danke für den Tip!

[Jörg Reinholz]

Tach!

Die Mühe beschränkt sich darauf, ein Häkchen zu setzen.

Jein. Zum ersten war zumindest bei mir Wireshark so konfiguriert, dass die Haken per default gesetzt waren. Zum zweiten braucht es eh eine Möglichkeit für den Entwickler z.B. um beim Entwickeln und Testen von Caching-Funktionen (z.B. für quasistatische Inhalte) auch mutwillig die Komprimierungsoptionen für den Abruf zu manipulieren.

Jörg Reinholz

[absolute beginner]

hi nochmal,

Die Mühe beschränkt sich darauf, ein Häkchen zu setzen.

Jein. Zum ersten war zumindest bei mir Wireshark so konfiguriert, dass die Haken per default gesetzt waren.

hm, die Häkchen waren bei mir auch gesetzt. Leider findet eine Dekomprimierung trotzdem nicht statt. Was könnte der Grund sein?

Die Lösung von Jörg finde ich auch sehr gut. Allerdings ist ja mein Endziel, Traffic anderer Geräte in meinem Wlan-Netzwerk mitzuschneiden. Da habe ich ja keinen Einfluss drauf, welche Browsereinstellungen diese haben. Es sei denn, ich wäre der Besitzer dieses Gerätes natürlich.

[Jörg Reinholz]

hm, die Häkchen waren bei mir auch gesetzt. Leider findet eine Dekomprimierung trotzdem nicht statt. Was könnte der Grund sein?

Das Du die Ausgabe nicht gefunden hast. Ich hab für Dich nachgeschaut:

Suche also im mittleren Fenster nach einer Antwort vom Server mit dem Protokoll oder der Info "HTTP/1.1. 200 OK".
Unter Data (xxxx Bytes) steht die zunächst die komprimierten Daten.
Schau  unter "Line based text-data: text/html" nach. Da steht der dekomprimierte Inhalt.

Jörg Reinholz

[absolute beginner]

oh, Mann,

Das Du die Ausgabe nicht gefunden hast. Ich hab für Dich nachgeschaut:

Suche also im mittleren Fenster nach einer Antwort vom Server mit dem Protokoll oder der Info "HTTP/1.1. 200 OK".
Unter Data (xxxx Bytes) steht die zunächst die komprimierten Daten.
Schau  unter "Line based text-data: text/html" nach. Da steht der dekomprimierte Inhalt.

Jörg, du bist der Hit. Mann, bin ich doof. auf meinem Laptop ist das Fenster so eng, dass diese Zeile nicht mehr sichtbar war. Gut, das ist beileibe keine Entschuldigung.

Also, danke nochmals! Damit kann ich arbeiten!
grüße
ab

[Jörg Reinholz]

Jörg, du bist der Hit.

Die Blumen gehen an Dedlfix.

Jörg Reinholz

[unknown]

Allerdings ist ja mein Endziel, Traffic anderer Geräte in meinem Wlan-Netzwerk mitzuschneiden.

Das sollte dir allerdings nicht gelingen, weil du den Traffic anderer Geräte nicht entschlüsseln können solltest.

[Der Martin]

Hallo,

Allerdings ist ja mein Endziel, Traffic anderer Geräte in meinem Wlan-Netzwerk mitzuschneiden.
Das sollte dir allerdings nicht gelingen, weil du den Traffic anderer Geräte nicht entschlüsseln können solltest.

warum nicht, wenn doch alle Geräte denselben WPA2-Key verwenden (müssen)?

So long,
 Martin

[unknown]

warum nicht, wenn doch alle Geräte denselben WPA2-Key verwenden (müssen)?

Weil du sonst andere Geräte ausspionieren könntest wie früher in einem BNC-Netzwerk.
Ich hatte mal ein schönes Bild gesehen, da hat man gut erkannt wie der Schlüssel zusammengebaut ist. Das finde ich jetzt nicht mehr so auf die schnelle. Auf jeden Fall findet ein re-keying statt, so dass sogar jedes Paket einen eigenen Schlüssel besitzt.

[unknown]

warum nicht, wenn doch alle Geräte denselben WPA2-Key verwenden (müssen)?

Weil du sonst andere Geräte ausspionieren könntest wie früher in einem BNC-Netzwerk.
Ich hatte mal ein schönes Bild gesehen, da hat man gut erkannt wie der Schlüssel zusammengebaut ist. Das finde ich jetzt nicht mehr so auf die schnelle. Auf jeden Fall findet ein re-keying statt, so dass sogar jedes Paket einen eigenen Schlüssel besitzt.

Hier sieht man es auch ganz gut.

[Der Martin]

Hi,

warum nicht, wenn doch alle Geräte denselben WPA2-Key verwenden (müssen)?
Weil du sonst andere Geräte ausspionieren könntest wie früher in einem BNC-Netzwerk.

oder auch in einem herkömmlichen Ethernet mit CATx-Verkabelung - wenn man entweder einen "dummen" Hub verwendet oder einen Switch mit Port Mirroring. Ich habe jedenfalls für solche Diagnoseaufgaben immer noch einen ordinären Hub im Köfferchen (die kriegt man ja heute kaum noch). Hat mir schon manches Mal weitergeholfen.
Zwar nur 10Mbit, bremst also die zu beobachtende Netzwerkverbindung etwas aus, das ist aber während der Fehlersuche meist akzeptabel.

Ich hatte mal ein schönes Bild gesehen, da hat man gut erkannt wie der Schlüssel zusammengebaut ist. Das finde ich jetzt nicht mehr so auf die schnelle. Auf jeden Fall findet ein re-keying statt, so dass sogar jedes Paket einen eigenen Schlüssel besitzt.
Hier sieht man es auch ganz gut.

Danke, das war mir bis dato nicht bekannt. Ich hatte mir tatsächlich schon mal Gedanken gemacht, wie das z.B. in Hotels oder bei öffentlichen WLAN-Hotspots gehandhabt wird - bisher hatte ich immer befürchtet, da könne ja jeder Teilnehmer nach Herzenslust mitlesen.

So long,
 Martin

[absolute beginner]

"auf welchem Rechner läuft Wireshark? Auf demselben Laptop, oder auf einem anderen Rechner, der ebenfalls am WLAN "teilnimmt"?"

ach, so, ja, auf demselben Laptop. Am Wlan nimmt sonst nur noch ein Android-Phone "teil".