Расшифруйте трафик SSL с помощью инструмента командной строки openssl - продолжение часть 5

Question

Из моих предыдущих сообщений, часть 1, часть 2, часть 3 и часть 4, я считаю, что все правильно рассчитал / расшифровал и готов попытаться расшифровать зашифрованное сообщение рукопожатия клиента. Я застрял на следующем шаге, как только у меня есть все ключи. Я читал и исследовал это в течение пары дней и просто застрял.

Следуя указаниям из моих предыдущих постов, я придумал

20 bytes for a client MAC key: 64666eafe1cbd51f2e2b50799b40f6007c3dc56f
20 bytes for a server MAC key: e0aac1312d35b5e8b6bf9af6ecf07e1dff27c784
32 bytes client encryption key:
4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808
32 bytes for a server encryption key:
 ca94445e3d771d3e06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff

Мое зашифрованное клиентское рукопожатие:

Hex.       FILE SIZE: 40
 ADDRESS   000 001 002 003 004 005 006 007       ASCII
===============================================================================
00000000   09A 01B 0F3 06B 078 06C 03B 059      ~Z  ^[  -s   k   x   l   ;   Y
00000008   085 061 07C 076 0AF 0D9 085 0D6      ~E   a   |   v  -/  -Y  ~E  -V
00000010   08F 0FD 0AF 06D 09F 01A 025 0EF      ~O  -}  -/   m  ~_  ^Z   %  -o
00000018   040 015 097 002 0B5 0AD 0EF 040       @  ^U  ~W  ^B  -5  --  -o   @
00000020   02B 0DB 051 096 0CE 076 0A9 03F       +  -[   Q  ~V  -N   v  -)   ?
00000028   0D7 030 049 03A 0CC 0F9 029 044      -W   0   I   :  -L  -y   )   D
00000030   07F 0A9 0C6 0F1 017 02D 06B 040      ^?  -)  -F  -q  ^W   -   k   @
00000038   035 0F5 057 08E 0BF 0E9 05C 06D       5  -u   W  ~N  -?  -i   \   m
00000040

Я считаю, что мне нужно использовать вариант openssl end -d -K, но спотыкаясь здесь между RFC и Google, чтобы найти решение / пример, который это четко объясняет. Кто-нибудь знает, как / если я могу сделать это в командной строке в openssl? Спасибо

Обновить. Я не уверен, почему / как я пропустил в RFC 7.4.9 PRF(master_secret, finished_label, Hash(handshake_messages)) Я записал все сообщения рукопожатия, может кто-то объяснить, как я могу смоделировать это с помощью только командной строки openssl с данными Я захватил / расшифровал до этого момента. Похоже, что хеш сообщений рукопожатия - это то, что мне нужно выполнить до этого раздела 5 RFC. Я предполагаю, что собираюсь использовать сгенерированный мной master_secret. Я не уверен, что начальное значение для этого должно использовать openssl, как Я ранее использовал это. Я не вижу, что для этого хэша есть сцепленная метка, так что я просто использую все рукопожатия, чтобы соединить эту точку вместе? Есть много шагов, которые я теряюсь, где я нахожусь. Спасибо

openssl dgst -sha256 -mac hmac -macopt hexkey:$key <seed -binary >a1

Answer 1

Я заинтригован тем, что вы, кажется, используете новый формат файлового дампа каждый раз, когда вы публикуете :-)

Предполагая, что вы, как и прежде, используете (RSA-with-)AES256CBC- (HMAC)SHA1: да, вы можете расшифровать шифры TLS CBC с помощью openssl enc, за исключением ARIA. (Также RC4, хотя вы должны избегать использования RC4 для любых целей, включая TLS. Ото enc не может делать какие - либо AEAD шифры:. Не GCM или СКК, а не чача /Poly) Формат записи в TLS1.2 (и 1.1) для шифра CBC описан в разделе 6.2.3.2 RFC5246. Для AES первые 16 октетов - это IV, а остальные - зашифрованный текст, который должен расшифровываться в текстовое тело записи текста (в данном случае в сообщение «Закончено») плюс HMAC плюс заполнение - но заполнение TLS отличается от PKCS5 /7 padding поддерживается enc (и внутри EVP_{??crypt,Cipher}* API), так что вам нужно сделать это самостоятельно.

Как описано на его справочной странице в вашей системе или в Интернете, и довольно много вопросов по нескольким стекам (хотя большинство из них я отмечал о соответствии командной строки с другим кодом, таким как Java и python и т.д., А не со спецификацией), по умолчанию в openssl enc для шифрования на основе пароля (PBE), который не то, что вы хотите здесь. Чтобы выполнить дешифрование на основе ключей, необходимо указать -d , -K (верхний регистр, не строчный) с ключом в шестнадцатеричном формате и -iv с IV в шестнадцатеричном, если используется шифром (AES-CBC делает):

$ echo $key; echo $iv
4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808
9A1BF36B786C3B5985617C76AFD985D6
$ sed 1,2d <1346633.dat
8FFDAF6D9F1A25EF
40159702B5ADEF40
2BDB5196CE76A93F
D730493ACCF92944
7FA9C6F1172D6B40
35F5578EBFE95C6D
$ sed 1,2d <1346633.dat |xxd -p -r |openssl aes-256-cbc -d -K $key -iv $iv -nopad |xxd
0000000: f730 34cc b90f b0b0 6313 9a0f 239c 6e87  .04.....c...#.n.
0000010: 187f ff00 52d1 3e9c 2aef d5cd c07e 15be  ....R.>.*....~..
0000020: dee0 aa95 6994 5ce6 768d 1952 ac00 17ba  ....i.\.v..R....

К сожалению, как вы можете видеть, это дешифрование недопустимо: оно не заканчивается заполнением в стиле TLS и не начинается с сообщения «Завершено», как и должно быть при первой клиентской передаче после CCS. Либо ваш производный ключ неверен, либо ваш дамп этой записи.

Одно предложение, которое может помочь: создайте соединение с помощью (отредактируйте) openssl s_client -debug и запишите его вывод в файл. Это сбрасывает все записи в шестнадцатеричном формате (и ASCII), которые вы можете использовать как данные для или для проверки различных входных данных (включая зашифрованную запись, содержащую Finished), а блок «SSL-Session» в конце включает правильное значение главный секрет, который вы можете использовать в качестве перекрестной проверки. Вы можете добавить -msg чтобы также получать дамп зашифрованных сообщений; это больше, но немного удобнее, и это то, что я сделал ниже. Другая возможность, чуть больше работы по настройке, - это подключиться из клиентской программы Java SSL/TLS (JSSE), запущенной с sysprop javax.net.debug=ssl и log; это сбрасывает много информации, включая главный секрет и рабочие ключи.

---

В качестве примера того, как это должно работать, я прошел процедуру во время сеанса регистрации в журнале (который я фактически создал для вашего первого Q несколько недель назад), выполняя вручную главный и рабочий деривации, расшифровывая и проверяя сообщение Finished на клиенте. :

$ cat tempc
2f e9 97 3e e4 11 89 81 c5 bc 18   11 7b c9 e9 3d
64 cb 88 6e a4 ac f2 01 95 05 d7
fe 3d 09 f4 13 4a d7 39 77 bf 50 dc f4 7b 9b b8
3c 0b 2f bf 98 5a 9c 4c 2d 28 6c 6a b6 93 a9 29
c5 5f f1 a3 cd
$ # this is the hexdump of from s_client -debug, cleaned up 
$
$ echo $key; echo $iv
7d18617e178fc6320019442c6cd071ca4b4f7d2bb83f6194c23681aefd84f120
2fe9973ee4118981c5bc18117bc9e93d
$ # you can see the IV is the first line (16 bytes) of tempc
$ sed 1d tempc |xxd -p -r |openssl aes-256-cbc -d -K $key -iv $iv -nopad |tee tempc! |xxd
0000000: 1400 000c 5bbc 39d8 6c5d dbb1 076b b91b  ....[.9.l]...k..
0000010: 9f4e 5c55 fd9e a185 6901 4bc0 6f02 2c0d  .N\U....i.K.o.,.
0000020: 5bb0 d8c9 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b  [...............
$ # those last 12 bytes are SSL/TLS-style padding 
$ # the first 4 bytes are a handshake message header for x14=Finished,
$ # followed by the 12 byte verify_data value, total 16 bytes 
$
$ echo $mkey
28a3244d49c644f889b44f2bae54466b6913fb1e
$ { printf '\0\0\0\0\0\0\0\0\x16\x03\x03\0\x10'; head -c16 tempc! ; } \
> |openssl sha1 -mac hmac -macopt hexkey:$mkey -binary |xxd -p 
9f4e5c55fd9ea18569014bc06f022c0d5bb0d8c9
$ # the 20 bytes after the 16-byte message and before the padding 
$ # correctly match HMAC-SHA1 of the pseudoheader plus the message

---

Что касается «verify_data» в сообщении Finished, да, вам нужно взять хеш всех предыдущих сообщений рукопожатия, как описано в 7.4.9 (в TLS1.3 это называется «транскриптом» хеша), а затем PRF ( как обсуждалось в предыдущих сообщениях), где ключ является главным секретом, а начальное число является фиксированной меткой «клиент завершен» или «сервер завершен» (в зависимости от ситуации) плюс этот хэш транскрипта. Это гораздо больше работы, и я не делал этого для примера, хотя, возможно, смогу при необходимости.