WPA и WPA2 используют ключи, полученные из рукопожатия EAPOL, для шифрования трафика. Если для сеанса, который вы пытаетесь расшифровать, присутствуют все четыре пакета подтверждения связи, Wireshark не сможет расшифровать трафик. Вы можете использовать фильтр отображения EAPOL, чтобы найти пакеты EAPOL в вашем захвате.
Я заметил, что расшифровка работает также с (1, 2, 4), но не с (1, 2, 3). Насколько я знаю, первых двух пакетов достаточно, по крайней мере для того, что касается одноадресного трафика. Может кто-нибудь объяснить, как именно Wireshark справляется с этим, другими словами, почему работает только предыдущая последовательность, учитывая, что четвертый пакет является просто подтверждением? Кроме того, гарантируется ли, что (1, 2, 4) всегда будет работать, когда (1, 2, 3, 4) работает?
Прецедент
Это рукопожатие (1, 2, 4) и зашифрованный ARP
пакет (SSID:, SSID
пароль :) password
в base64
кодировке:
H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj / n4GhHkhfXNHr37KQgWEqAwQzMAgx 6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4 + СПЦ + H0MngwLUZMarj4Rn S8vInf5yfO7mgrMyr9g / Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn ITk1gBnJkeX / GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz + VGLl + snrF7j2EnHQy3JjDKPb9 3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ 9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT + 0 / J3LP gie59HFL + 5RDIdmZ8rGMEldN5s668eb / tp8vQ + 7OrT9jPj / B7425QIGJI3Pft72dLxav8BefvcGU 7 + kfABxJX + SjAgAA
Расшифровать с помощью:
$ base64 -d | gunzip > handshake.cap
Запустите, tshark
чтобы увидеть, правильно ли он расшифровывает ARP
пакет:
$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID
Следует напечатать:
1 0,000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Ключ EAPOL 2 0.006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Ключ EAPOL 3 0.038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Ключ EAPOL 4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 в 00: a0: c5: 68: 3a: e4
Ответы:
Обмены EAPOL также используются для обновления временных ключей. Новые ключи устанавливаются на соискателя после его отправки 4/4 и устанавливаются на аутентификаторе, когда он получает 4/4 [1]. Если Wireshark должен правильно обрабатывать повторный ввод, он должен использовать ключи только после чтения пакета 4/4 в кадре, потому что пакеты могут все еще передаваться во время повторного ввода (даже в случае, когда они не должны, из-за буферизации)
Для первых 4WHS возможно не ждать 4/4, но вполне понятно, что им просто лень это реализовывать. 3/4 по-прежнему необходим, поскольку он содержит групповые ключи (даже если вы не заинтересованы в них, но знаете, что вы не увидите ARP-запросы от точки доступа или клиента, для которых у вас нет части его 4WHS) и ключи управления. Вы также можете пропустить 3/4, но тогда у вас нет подтверждения, что обмен был успешным, потому что 3/4 используется для проверки того, что Аутентификатор знает PMK.
[1] Обратите внимание, что при текущей схеме, если сообщение 4/4 потеряно, соискатель начал использовать новый ключ, а аутентификатор все еще использует старый ключ, и повторная отправка 3/4, зашифрованная старым ключом, не поможет , Эта проблема, среди многих других с WPA2, решена в последнем стандарте 802.11 2012 года, когда параллельно удерживаются два ключа.
источник
Вся информация, необходимая для создания PTK, обменивается на шагах 1 и 2. Этого должно быть достаточно для расшифровки одноадресного трафика.
Без шага 3 у вас не будет GTK, поэтому расшифровка многоадресной / широковещательной передачи невозможна.
Шаг 4 не является действительно необходимым для расшифровки перехваченного трафика, но если нет шага 4, клиент / точка доступа не начнет использовать шифрование. Wireshark может отключить это до того, как попытается расшифровать данные.
источник
Ну, очевидно, документация WireShark неверна. :-)
Сойдя с документации здесь :
Таким образом, это имеет смысл. WireShark не нужно сообщение 3 ни для чего. Он знает ключи после сообщений 1 и 2, но ожидает начала их использования для расшифровки трафика, пока не получит сообщение 4.
Нет никаких гарантий на что-либо в жизни, особенно на поведение свободного программного обеспечения, но разумно поспорить, что не будет необходимости для сообщения 3, чтобы WireShark расшифровывал сеанс.
источник
Это не объясняет почему, но в любом случае цитирование из документации airdecap-ng ,
источник