Могу ли я получить секреты TLS от HTTP-клиента для расшифровки моего собственного HTTPS-разговора?
Я создаю регистратор веб-сайтов, который действует как прокси-сервер, для постоянного тестирования веб-скребков. Он разделен на три контейнера Docker, все на GNU/Linux: (1) прокси-сервер, (2) API и очередь запросов и (3) простое веб-приложение.
Это отлично работает для HTTP-сайтов: я нажимаю кнопку в веб-приложении, это делает запрос в контейнер API, и это добавляет что-то во внутреннюю очередь запросов, которая затем запрашивает сайт через прокси-сервер. Прокси-сервер записывает сайт так, как он проходит насквозь.
Однако я забыл, что нельзя записывать трафик сайта HTTPS, и теперь, когда я пришел к этому, я обнаружил, что прокси-серверы просто используют глагол CONNECT, а затем действуют как обмен данными между клиентом и целью. Я считаю, что не могу воспроизводить одни и те же фрагменты данных, так как часть шифрования использует случайный, одноразовый симметричный ключ (однако у меня есть сценарий, подходящий для тестирования этого, поэтому я сделаю это только для образовательной ценности!).
Итак, мне было интересно если бы мой клиент выборки мог выдать достаточно секретов, чтобы прокси-система могла декодировать поток байтов? Я использую Wget для выполнения выборки, которая, как я предполагаю, будет использовать OpenSSL. Это не обязательно должно быть Wget, хотя: если бы я использовал PHP-скрипт с file_get_contents в контексте потока могу ли я попросить модуль openssl предоставить ключи расшифровки?
(Честно говоря, я, вероятно, не решу проблему таким образом, даже если это возможно, я просто подумал, что было бы действительно интересно узнайте немного больше о TLS. На практике я буду записывать "нулевую" запись для всех защищенных веб-сайтов в прокси-сервере и требовать, чтобы запрашивающая служба уведомляла прокси-сервер о данных заголовка/тела с помощью вызова API, чтобы их можно было позже воспроизвести. У них, конечно, будут копии этих предметов в открытом виде).
1 answers
Да, я думаю, у вас есть несколько вариантов здесь.
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. Этот формат может быть прочитан wireshark и позволит расшифровать сеанс для отладки.
Попробуйте установить SSLKEYLOGFILE переменную среды в имя файла и посмотрите, будет ли wget затем записывать ваши ключи сеанса TLS в этот файл? Возможно, вам потребуется перекомпилировать wget с отладочной сборкой GnuTLS. Я сам этого не пробовал.