Non-RSA TLS1.2 Расшифровка пакетов

Question

Я пытаюсь расшифровать файл pcap. Этот файл pcap содержит захват зашифрованного видео потока HLS. Pcap содержит пакеты TLSv1.2.

Ниже приведены некоторые данные из файла PCAP

сервера Привет сообщение Cipher Suite:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

EC сервер Диффи-Хеллмана Params: Публичных (1)

Состояние сертификата сообщение:

Подпись Hash Algorithm Hash: SHA256

Подпись Hash Algorithm Подпись: ECDSA

Клиентский обменный код

EC Диффи-Хеллмана сервера Params: Публичных (2)

Я пытался следовать this Wireshark SSL decryption tutorial. Но похоже, что он работает только для шифрования RSA. Я искал какое-то время и нашел this discussion. Я цитирую отрывок из этой дискуссии:

Существует очень важный параметр для ума: дешифрование пассивно записанной сессии (с копией секретного ключа сервера) работает только тогда, когда обмена ключей был типа RSA или статический DH; с наборами «DHE» и «ECDHE» , вы не сможете расшифровать такой сеанс, даже с знаниями секретного ключа сервера. В этом случае вам нужно будет либо переговоров «главный секрет», или использовать серверную частный ключ активно перехватывать соединительном

сведению это достойно, что у меня есть секретный ключ клиента. В моем случае клиентом является видеопоток FFmpeg (FFplay). Я также посмотрел на TLS v1.2 RFC.

Мой вопрос:

Можно ли сделать расшифровку в этом случае? Если да, что мне нужно сделать для этого?

Выполняется ли дешифрование с использованием закрытого ключа клиента или с использованием pre_shared_master (т. Е. Diffie-Hellman)?

Answer 1

Нет, это невозможно расшифровать в этом сценарии. Это будет связано с нарушением EC Diffie-Hellman.

дешифрование не непосредственно выполняется с использованием pre_master_secret, но она выполняется с помощью клавиш получены непосредственно из предварительно главного секрета. То есть: ключи дешифрования клиента и сервера, которые производятся от него, сначала вызывая master_secret, а затем выполняя PRF и деля вывод на ключи сеанса и IV.

Answer 2

Во-первых, закрытый или закрытый ключ клиентов не участвует в обмене ключами каким-либо образом, а используется только для аутентификации клиента (если запрашивается сервером). В обмене ключами используются серверы закрытый и открытый ключ, но только если используется обмен ключами RSA. Для DHE/ECDHE они не используются, поэтому закрытого/открытого ключа недостаточно. См. it is possible to decrypt HTTPS with the (private, public) pair if it uses DHE?, чтобы узнать, почему это так.

Что вам понадобится вместо частного ключа - это фактически обменный ключ, который уникален для каждого сеанса TLS, даже если закрытый ключ является тем же.Некоторые клиенты могут хранить этот ключ для последующего использования, и если ваш клиент может это сделать, см. Decrypting TLS Browser Traffic With Wireshark – The Easy Way!, как действовать дальше, чтобы расшифровать трафик.