Я заинтригован тем, что вы, кажется, используете новый формат файлового дампа каждый раз, когда вы публикуете :-)
Предполагая, что вы, как и прежде, используете (RSA-with-) AES256CBC- (HMAC) SHA1: да, вы можете расшифровать шифры TLS CBCopenssl enc, за исключением ARIA. (Также RC4, хотя вам следует избегать использования RC4 для любых целей, включая TLS. OTOH encне может использовать никакие шифры AEAD: не GCM или CCM, а не ChaCha / Poly.) Формат записи в TLS1.2 (и 1.1) для Шифр CBC описан в разделе 6.2.3.2 RFC5246 . Для AES первые 16 октетов - это IV, а остальные - зашифрованный текст, который должен расшифровываться в текстовое тело записи текста (в данном случае в сообщение «Закончено») плюс HMAC плюс заполнение - но заполнение TLS отличается от PKCS5 / 7 отступы поддерживаются enc(и внутренне EVP_{??crypt,Cipher}*API), поэтому вам нужно сделать это самостоятельно.
Как описано на его man-странице в вашей системе или в Интернете, и довольно много вопросов по нескольким стекам (хотя большинство из них я отмечал о соответствии командной строки с другим кодом, таким как Java и python и т. Д., А не со спецификацией), по openssl encумолчанию пароль основанное шифрование (РОВ), который является не то, что вы хотите здесь. Для того, чтобы сделать « на основе ключей» расшифровку, вам нужно указать -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 ( как обсуждалось в предыдущих сообщениях), где ключ является главным секретом, а начальное число является фиксированной меткой «клиент завершен» или «сервер завершен» (в зависимости от ситуации) плюс этот хэш транскрипта. Это гораздо больше работы, и я не делал этого для примера, хотя, возможно, смогу при необходимости.