Могу ли я получить секреты TLS от HTTP-клиента, чтобы расшифровать мою собственную беседу HTTPS?

Я создаю рекордер на веб-сайте, который действует как прокси-сервер, чтобы протестировать веб-скребки на постоянной основе. Он разделен на три контейнера Docker, все на GNU/Linux: (1) прокси, (2) очередь API и запросов и (3) простое веб-приложение.

Он отлично работает для сайтов HTTP: я нажимаю кнопку в веб-приложении, это делает запрос в контейнер API и добавляет что-то во внутреннюю очередь запросов, которая затем запрашивает сайт через прокси-сервер. Прокси записывает сайт по мере его прохождения.

Однако я забыл, что нельзя отслеживать трафик сайта HTTPS, и теперь я пришел к этому, я обнаружил, что прокси используют только глагол CONNECT, а затем действуют как обмен данных между клиента и цели. Я считаю, что не могу воспроизвести одни и те же фрагменты данных, поскольку часть шифрования использует рандомизированный симметричный ключ (однако у меня есть script, подходящий для тестирования, поэтому я сделаю это только для образовательной ценности!).

Итак, мне было интересно, может ли мой получающий клиент отдать достаточно секретов для прокси-системы для декодирования байтового потока? Я использую Wget для выполнения выборки, которая, я думаю, будет использовать OpenSSL. Однако не обязательно иметь Wget: если бы я использовал PHP script с file_get_contents с контекстом потока, могу ли я задать модуль openssl для ключей дешифрования?

(Справедливости ради, я, вероятно, не решит проблему таким образом, даже если это возможно, я просто подумал, что было бы действительно интересно узнать немного больше о TLS. На практике я буду записывать "нулевое" значение, запись обо всех защищенных веб-сайтах в прокси-сервере и потребовать, чтобы запрашивающая служба уведомила прокси-данные о данных заголовка/тела с помощью вызова API, чтобы впоследствии его можно было воспроизвести. Конечно, у них будут текстовые копии этих элементов).

Ответы

Ответ 1

Да, я думаю, у вас здесь пара вариантов.

HTTPS специально разработан, чтобы помешать атакам "Человек в середине" и подслушивающим устройствам, что по сути является тем, чего вы пытаетесь достичь. Однако вы можете сломать некоторые из своих предположений и победить его.

В начале соединения SSL: 1. удаленный сервер представляет свой открытый ключ и его сертификат, 2. клиент проверяет сертификат и 3. отправляет ключ сеанса, зашифрованный открытым ключом сервера. Более подробно см., Например, Обзор протокола SSL или TLS

У вас есть два возможных способа обойти эту защиту в описываемом вами сценарии:

1. Перепишите данные TLS, заменив серверный сертификат и ключ на свой собственный

Поскольку вы управляете каналом связи, вы можете заменить открытый ключ сервера и сертификат на тот, который вы контролируете, на шаге (1). Если вы затем попросите клиента пропустить шаг (2) с помощью аргумента --no-check-certificate до wget, вы можете получить полный доступ к зашифрованным данным.

Так прокси-сервер отладки Fiddler разрешает доступ к трафику HTTPS, см. https://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp

2. Получить ключ сеанса из клиентского приложения

Так как клиентское приложение знает ключ сеанса, если вы можете его извлечь, вы можете затем расшифровать поток. Я думаю, это то, что вы имели в виду в вопросе.

wget сам по себе не имеет возможности разрешить ведение журнала ключа сеанса (см. " HTTPS (SSL/TLS), но это выглядит как его библиотека TLS," GnuTLS "имеет параметр отладки, который будет делать то, что вы хотите, см. " Отладка и аудит "в документах GnuTLS:

SSLKEYLOGFILE При установке имени файла GnuTLS добавит к нему ключи сеанса в формате журнала NSS. Этот формат может быть прочитан wirehark и позволит расшифровать сеанс для отладки.

Попробуйте установить переменную среды SSLKEYLOGFILE в имя файла и посмотрите, будет ли wget записывать ваши ключи сеанса TLS в этот файл? Возможно, вам придется перекомпилировать wget с помощью отладочной сборки GnuTLS. Я сам этого не пробовал.