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

Question

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

457

David B 2018-07-26 в 13:41

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

openssl rsautl -in cpre.key -inkey key.pem -decrypt -out spre.key

Это создало мой секретный файл pre master 48-байтового сервера spre.key (я думаю, что это правильно) и в десятичном виде для (просмотр с использованием кровати) как:

003 003 203 048 063 215 047 196 221 221 221 014 019 072 011 100 217 080 111 073 217 026 234 082 022 217 232 025 096 063 115 080 016 094 015 170 148 126 092 118 109 228 246 149 208 195 044 220

шестнадцатеричный: 0303CB303FD72FC4DDDDDD0E13480B64D9506F49D91AEA5216D9E6016F0F0F5F5F095D5F5F5F5F5F5F5015R5F5015R5F5015D5

И конкатенируя буквальный «главный секрет» + client.random + server.random, я создал mseed.key и снова просмотрел с кроватью так же, как и десятичное, которое я создал:

109 097 115 116 101 114 032 115 101 099 114 101 116 173 212 147 215 014 129 225 102 157 027 001 125 167 097 014 085 064 025 114 025 024 248 096 254 044 235 151 130 033 151 015 133 251 114 232 095 213 076 194 057 175 106 225 088 206 069 187 050 168 031 217 080 198 061 180 043

Hex: 6D617374657220736563726574ADD493D70E81E1669D1B017DA7610E554019721918F860FE2CEB978221970F85FB72E85FD54CC239AF6AE158CE45BB32A81FD950C63DB42B
в общей сложности 69 байт

Далее я ставлю, что вместе, и так как я был проинформирован о том, что данные, находящиеся в бинарных файлах я использовал следующее для создания мастер - секрета и ключей.

openssl dgst -sha256 -hmac spre.key <mseed.key -binary >a1 openssl dgst -sha256 -hmac spre.key <a1 -binary >a2 openssl dgst -sha256 -hmac spre.key <a2 -binary >a3 openssl dgst -sha256 -hmac spre.key <a3 -binary >a4

Это создало 4 32-байтовых файла.

затем создаем ключи с помощью:

cat a1 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k1 cat a2 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k2 cat a3 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k3 cat 42 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k4

Это создало 4 32-байтовых файла.

Следуя приведенным мной примерам и читая RFC, насколько я понимаю, главный ключ на этом этапе - это первые 48 байтов a1 + a2, это правильно или я что-то упустил? Так как я на самом деле не могу увидеть, что PRF master_secret возвращает или делает, я думаю, что из командной строки, как описано выше, я получу главный секрет. Спасибо Дэвид

0

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

2

Accepted Answer · 2018-07-27 04:59:20

Во-первых, ваш файл mseed (метка + начальное значение в PRF) должен быть 77 байтов, а не 69. Вы, должно быть, каким-то образом испортили одноразовые номера клиента и / или сервера.

Во-вторых, -hmac spre.keyэто неправильно. В качестве ключа HMAC используются фактические символы, s p r e . k e y т. Е. Октеты 73 70 72 65 2e 6b 65 79. Вам необходимо использовать значение расшифрованного секрета premaster, которое является содержимым вашего файла spre.key. А поскольку это двоичные данные, которые могут включать байты, которые представляют собой специальные коды символов, такие как нуль, табуляция, долларовый знак, кавычка, обратная косая черта, удаление и т. Д., Вы не можете безопасно передавать их напрямую, -hmac или даже -hmac ''; вместо этого вам нужно использовать, -mac hmac -macopt hexkey:как я показал в предыдущем ответе, за исключением использования фактического значения шестнадцатеричного ключа, которое вы показали в этом вопросе, а именно 0303CB30...2CDC.

В-третьих, как я показал в предыдущем ответе, вы объединяете результаты второго уровня HMAC, то есть в моих обозначениях k1, k2, ..., чтобы сформировать вывод (который в этом примере был 100 октетов):

$ cat k1 k2 k3 k4 | head -c100 | xxd

но как я сказал дальше:

... и для фактического рукопожатия TLS1.2, настроенного на правильную длину: 48 для главного секрета и в зависимости от набора шифров для рабочих ключей.

Для первого (premaster-to-master) деривации вам нужно 48 октетов, поэтому вам нужны только первые два блока по 32 (a0-> a1-> a2 a1 + a0-> k1 a2 + a0-> k2), затем конкатенируйте k1 + k2 и возьмите первые 48 октетов.

Для второго (мастер-работающего) деривации необходимая длина зависит от согласованного набора шифров. Вы сказали, что используете RSA-with-AES256CBC-SHA, которому (в TLS1.2 или 1.1, но не 1.0) требуется 40 октетов ключей HMAC и 64 октета ключей шифрования, общим объемом 104 октета. Для 104 ocets вам нужно вычислить 4 порции по 32, объединить k1 + k2 + k3 + k4 и разложить их на client-MAC, server-MAC, client-encryption, server-encryption в этом порядке. Смотрите 6.3 RFC. Также обратите внимание, что метка отличается, и для этого деривации начальное число (метка +) server_random + client_random, а не (метка +) client_random + server_random, как в первом.

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

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

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