Расшифруйте трафик SSL с помощью инструмента командной строки openssl 8

341
David B

Для моих заключительных шагов в моем сценарии я следовал за этим, чтобы получить ключ шифрования клиента, чтобы выполнить расшифровку с.

client.random xxd -p crnd.bin

5b689404b500456eef2f1a79ec782eb3eeaac3a8d7c02ae03c8426f363b1 8a33 

server.random xxd - srnd.bin

5b6894043bb1289e158b0278ef66dc53c9fa71e75e900739af2657cd4476 ec1e 

(echo -n расширение ключа; cat srnd.bin crnd.bin)> master_seed.key
xxd -p master_seed.key

6b657920657870616e73696f6e 5b6894043bb1289e158b0278ef66dc53c9 fa71e75e900739af2657cd4476ec1e 5b689404b500456eef2f1a79ec782e b3eeaac3a8d7c02ae03c8426f363b18a33 note: as before the spaces are not there I added them for clarity  key=$(cat master_secret.hex)  openssl dgst -sha256 -mac hmac -macopt hexkey:$key <master_seed.key -binary >a1 openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a1 -binary >a2 openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a2 -binary >a3 openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a3 -binary >a4 ## cat a1 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k1 cat a2 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k2 cat a3 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k3 cat a4 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k4 cat k1 k2 k3 k4 | head -c104 | xxd -p -c104 > k1_k4.hex truncate -s-1 k1_k4.hex  $cat k1_k4.hex 64666eafe1cbd51f2e2b50799b40f6007c3dc56fe0aac1312d35b5e8b6bf9af6ecf07e1dff27c784 4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808ca94445e3d771d3e 06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff dd bs=40 count=1 if=k1_k4.hex of=cmackey.hex 2>/dev/null dd bs=40 count=1 skip=1 if=k1_k4.hex of=smackey.hex 2>/dev/null dd bs=80 skip=1 if=k1_k4.hex 2>/dev/null | dd bs=64 count=1 of=cenckey.hex 2>/dev/null dd bs=80 skip=1 if=k1_k4.hex 2>/dev/null | dd bs=64 skip=1 count=1 of=senckey.hex 2>/dev/null 

$ cat cmackey.hex

64666eafe1cbd51f2e2b50799b40f6007c3dc56f 

$ cat smackey.hex

e0aac1312d35b5e8b6bf9af6ecf07e1dff27c784 

$ cat cenckey.hex

4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808 

$ cat senckey.hex

ca94445e3d771d3e06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff 

Зашифрованное рукопожатие

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 64 Handshake Protocol: Encrypted Handshake Message  Handshake Protocol: Encrypted Handshake Message 16030300409a1bf36b786c3b5985617c76afd985d68ffdaf 6d9f1a25ef40159702b5adef402bdb5196ce76a93fd73049 3accf929447fa9c6f1172d6b4035f5578ebfe95c6d 

Сохранены только зашифрованные данные (последние 64 байта в cenc.dat) $ xxd -p cenc.dat

9a1bf36b786c3b5985617c76afd985d6 8ffdaf6d9f1a25ef40159702b5ad ef402bdb5196ce76a93fd730493accf929447fa9c6f1172d6b4035f5578e bfe95c6d Note: space added again for clarity 

$ xxd -p iv.bin

9a1bf36b786c3b5985617c76afd985d6 

$ xxd -p encmsg.bin

8ffdaf6d9f1a25ef40159702b5adef402bdb5196ce76a93fd730493accf9 29447fa9c6f1172d6b4035f5578ebfe95c6d 

Прошлой

$cat encmsg.bin | openssl aes-256-cbc -d -K $key -iv $iv -nopad |xxd gives the same result of bad decrypted data not a finished (14) record 

Dave, при сравнении моего выходного байта с байтом я не вижу проблем с моими шагами. Я проверил это десяток или более раз вручную и вызывал свой сценарий, и я получаю тот же вывод, который неверен, как вы указали, что он не расшифровывается до завершающего сообщения. Вы что-нибудь заметили здесь? Спасибо

0
Кто такой Дейв? .... djsmiley2k 5 лет назад 1
Человек, который помогал мне. Надеюсь, что это было не так, чтобы направить это ему. Я сделал это на моих предыдущих постах. David B 5 лет назад 0
Это просто сбивает с толку читать. Это все. djsmiley2k 5 лет назад 0
Возможно, @_daveSomethingOrOther_ для его идентификатора обмена стека поможет Hogstrom 5 лет назад 0
Нет, я ничего не замечаю. Единственная оставшаяся возможность, о которой я могу думать, состоит в том, что ваши системы использовали (согласились) [расширение расширенного главного секрета] (https://tools.ietf.org/html/rfc7627), которое (радикально!) Изменяет вывод главного секрета, и таким образом, конечно, ключи. Проверьте ClientHello и ServerHello в перехвате, чтобы увидеть, содержат ли они _both_ это расширение (0017 в шестнадцатеричном или 23 десятичном, если wireshark не декодирует его). dave_thompson_085 5 лет назад 0
@Hogstrom: @ -notify работает только для людей, которые уже «присутствуют» на этом вопросе, а НЕ по всему миру. См. Примечание 1 в справочной ссылке для поля комментария или более подробные https://meta.stackexchange.com/questions/43019/how-do-comment-replies-work. Аскер прокомментировал [предыдущий Q] (https://superuser.com/questions/1347558/), где я был единственным другим комментатором, который автоматически «пинговал» меня. dave_thompson_085 5 лет назад 0
Спасибо, дайте мне посмотреть мои журналы и RFC7627. Я слышал от нашего системного администратора, который будет работать над добавлением библиотек к нашему паролю, работающему поверх unix. Это должно упростить ситуацию, но нет никакой информации о том, когда мне это будет доступно. David B 5 лет назад 0
вот и все! Клиент отправил 17 (23) для расширенного рукопожатия. Я не заметил, что я закодировал свой ответ с 17, что также указывает на то, что мой сервер тоже. Я изменил свой ответ, чтобы не использовать расширенный главный секрет, и расшифровка сработала. Я разместил свой следующий предмет, чтобы, надеюсь, приблизиться к завершению [здесь] (https://superuser.com/questions/1348665/decrypt-ssl-traffic-with-the-openssl-command-line-tool-9), который вы принимаете Посмотри, Дэйв, спасибо. David B 5 лет назад 0

0 ответов на вопрос

Похожие вопросы