Von dieser Wiki-Seite :
WPA und WPA2 verwenden Schlüssel, die von einem EAPOL-Handshake abgeleitet sind, um den Datenverkehr zu verschlüsseln. Solange nicht alle vier Handshake-Pakete für die Sitzung vorhanden sind, die Sie entschlüsseln möchten, kann Wireshark den Datenverkehr nicht entschlüsseln. Sie können den Anzeigefilter eapol verwenden, um EAPOL-Pakete in Ihrer Erfassung zu lokalisieren.
Ich habe bemerkt, dass die Entschlüsselung auch mit (1, 2, 4) funktioniert, aber nicht mit (1, 2, 3). Soweit ich weiß, reichen die ersten beiden Pakete zumindest für den Unicast-Verkehr. Kann jemand bitte genau erklären, wie Wireshark damit umgeht, mit anderen Worten, warum funktioniert nur die vorherige Sequenz, da das vierte Paket nur eine Bestätigung ist? Ist auch garantiert, dass (1, 2, 4) immer funktioniert, wenn (1, 2, 3, 4) funktioniert?
Testfall
Dies ist der gzippte Handshake (1, 2, 4) und ein verschlüsseltes ARP
Paket (SSID :, SSID
password :) password
bei der base64
Codierung:
H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj / n4GhHkhfXNHr37KQgWEqAwQzMAgx 6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4 + RmSH + H0MngwLUZMarj4Rn S8vInf5yfO7mgrMyr9g / Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn ITk1gBnJkeX / GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz + VGLl + snrF7j2EnHQy3JjDKPb9 3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ 9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT + 0 / J3LP gie59HFL + 5RDIdmZ8rGMEldN5s668eb / tp8vQ + 7OrT9jPj / B7425QIGJI3Pft72dLxav8BefvcGU 7 + kfABxJX + SjAgAA
Dekodieren mit:
$ base64 -d | gunzip > handshake.cap
Führen tshark
Sie Folgendes aus, um zu überprüfen, ob das ARP
Paket korrekt entschlüsselt wurde :
$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID
Es sollte drucken:
1 0,000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 EAPOL-Schlüssel 2 0,006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 EAPOL-Schlüssel 3 0.038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 EAPOL-Schlüssel 4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 ist um 00: a0: c5: 68: 3a: e4
quelle
Antworten:
EAPOL-Vermittlungen werden auch verwendet, um die temporären Schlüssel zu erneuern. Die neuen Schlüssel werden nach dem Senden von 4/4 auf dem Supplicant installiert und beim Empfang von 4/4 auf dem Authenticator [1] installiert. Wenn Wireshark die Neuverschlüsselung korrekt handhaben muss, darf es die Schlüssel erst nach dem Lesen des 4/4-Pakets im Frame verwenden, da möglicherweise noch Pakete während der Neuverschlüsselung fließen (auch wenn dies aufgrund der Pufferung nicht der Fall sein sollte).
Beim ersten 4WHS ist es möglich, nicht auf 4/4 zu warten, aber es ist durchaus verständlich, dass die Implementierung nur faul war. 3/4 ist weiterhin erforderlich, da es Gruppenschlüssel enthält (auch wenn Sie nicht daran interessiert sind, aber wissen, dass Sie keine ARP-Anforderungen vom AP oder einem Client sehen, für den Sie keinen Teil des 4WHS haben) und Verwaltungsschlüssel. Sie können auch 3/4 überspringen, haben aber keine Bestätigung, dass der Austausch erfolgreich war, da mit 3/4 überprüft wird, ob der Authentifikator das PMK kennt.
[1] Beachten Sie, dass mit dem aktuellen Schema, wenn die 4/4-Nachricht verloren geht, der Supplicant den neuen Schlüssel verwendet und der Authentifikator weiterhin den alten Schlüssel verwendet und das erneute Senden von mit dem alten Schlüssel verschlüsselten 3/4 nicht hilft . Dieses Problem, unter anderem mit WPA2, wird im neuesten 802.11 2012-Standard behoben, indem zwei Schlüssel parallel gehalten werden.
quelle
Alle zum Aufbau des PTK erforderlichen Informationen werden in den Schritten 1 und 2 ausgetauscht. Dies sollte ausreichen, um den Unicast-Verkehr zu entschlüsseln.
Ohne Schritt 3 ist die GTK nicht verfügbar, sodass Multicast / Broadcast nicht entschlüsselt werden kann.
Schritt 4 ist nicht wirklich erforderlich, um den erfassten Datenverkehr zu entschlüsseln. Wenn jedoch kein Schritt 4 ausgeführt wird, verwendet der Client / AP die Verschlüsselung nicht. Wireshark kann dies deaktivieren, bevor es versucht, Daten ebenfalls zu entschlüsseln.
quelle
Nun, offensichtlich ist die WireShark-Dokumentation falsch. :-)
Abgehend die Dokumentation hier :
Das macht also Sinn. WireShark benötigt für nichts Nachricht 3. Er kennt die Schlüssel nach den Nachrichten 1 und 2, wartet jedoch, bis er die Nachricht 4 empfangen hat, damit, den Datenverkehr zu entschlüsseln.
Es gibt keine Garantie für irgendetwas im Leben, insbesondere für das Verhalten freier Software, aber es ist eine vernünftige Wette, dass keine Nachricht 3 vorhanden sein muss, damit WireShark die Sitzung entschlüsseln kann.
quelle
Dies erklärt nicht, warum, aber trotzdem aus der Dokumentation der Flugsicherung zu zitieren,
quelle