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

Question

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

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

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

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 220

Hex: 0303CB303FD72FC4DDDDDD0E13480B64D9506F49D91AEA5216D9E819603F7350105E0FAA947E5C766DE4F695D0C32CDC

И конкатенируя буквальный "главный секрет" + 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: 6D617374657220736563726574ADD493D70E81E1669D1B017DA7610E554019721918F860FE2CEB978221970F85FB72E85FD54CC239AF6AE158CEFF54AE158CE45BB32A81FD950C63DB42B
всего 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 возвращает или делает, я думаю, что из командной строки, как описано выше, я получу главный секрет. Спасибо Дэвид

Answer 1

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

Во-вторых, -hmac spre.key сильно ошибается. Он использует фактические символы s p r e . k e y т.е. октеты 73 70 72 65 2e 6b 65 79 в качестве ключа HMAC. Вам необходимо использовать значение расшифрованного секрета premaster, которое является содержимым вашего файла spre.key. И поскольку это двоичные данные, которые могут включать байты, которые представляют собой специальные коды символов, такие как null, tab, dollarign, кавычка, обратная косая черта, delete и т.д., Вы не можете безопасно передавать их напрямую, как -hmac {key} или даже -hmac '{key}' ; вместо этого вам нужно использовать -mac hmac -macopt hexkey:{hex key value} как я показал в предыдущем ответе, за исключением использования фактического значения шестнадцатеричного ключа, которое вы показали в этом Q, а именно 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, как в первом.