TLS 1.3 и дешифровка

В одном из прошлых постов про дешифровку трафика в Wireshark рассказывалось, что протокол TLS 1.3 убрал поддержку статичных RSA ключей (Forward Secrecy). Т.е. в TLS 1.3 невозможно пассивно расшифровывать трафик дав маршрутизатору доступ к секретному ключу сервера (private key).

HTTP/3 использует протокол QUIC, который работает в связке с TLS 1.3. Т.е. будущее веб трафика за шифрованием TLS 1.3. Поскольку большая часть интернет трафика состоит из веб трафика будет полезным разобраться как его можно дешифровать для устранения проблем в приложениях и диагностики.

Какие же могут быть варианты расшифровки трафика TLS 1.3?

Полный прокси - терминировать TLS 1.3 сессию на прокси сервере, изучать открытым текстом, и передавать дальше. Прокси сервер будет находиться между клиентом и сервером.
Экспорт ключа сессии - терминировать TLS 1.3 сессию на веб-сервере, но использовать приложение на веб сервере которое экспортирует ключи сессии.

Вероятно основным способом дешифровки станет MITM прокси. Хотя MITM в сфере информационной безопасности рассматривается как перехват трафика с преступными целями, во время разработки приложений может потребоваться просмотреть (или даже модифицировать) зашифрованный трафик между клиентом и сервером. Пример приложения, которое позволяет это сделать - MitmProxy.

MitmProxy

Конфигурация сети может быть следующая

Клиент <---> MitmProxy (Режим прозрачного прокси (Transparent Proxy mode)) + Wireshark <---> Сервер

Прозрачный прокси

означает, что никаких настроек на клиенте делать не нужно. Шлюз по умолчанию будет сам перенаправлять зашифрованный трафик на прокси. MitmProxy может быть установлен на одной машине вместе со шлюзом по умолчанию (default gateway). Тогда его настройку можно передать автоматически клиентам по DHCP. Проблему в прозрачном режиме может создать ICMP Redirect.

ICMP redirect

ICMP redirect происходит в том случае, когда все три адреса: клиент (1), прокси сервер (2) и шлюз по умолчанию для прокси сервера (3) находятся в одной подсети. Рассмотрим пример:

10.10.0.1 - адрес шлюза по умолчанию для прокси сервера
10.10.0.2 - адрес прокси сервера и он же шлюз по умолчанию для клиента
10.10.0.101 - адрес клиента

Клиент использует адрес 10.10.0.2 как шлюз по умолчанию.

Получив подключение от клиента прокси сервер проверяет адрес назначения 195.201.201.32.
Сверившись со своей таблицей маршрутизации прокси сервер отправляет сообщение на адрес 10.10.0.1 (для этого должен быть включён ip forwarding).
А также прокси сервер может отправить ICMP redirect клиенту. ICMP redirect это сигнал о том, что существует более оптимальный маршрут.
В данном случае прокси сообщит клиенту, что существует лучший маршрут через шлюз 10.10.0.1.

ICMP:redirect sent to 10.10.0.101 for dest 195.201.201.32, use gw 10.10.0.1

Запуск MitmProxy

Команда запуска MitmProxy:

SSLKEYLOGFILE="$PWD/mitmproxy/sslkeylogfile.txt" mitmweb --mode transparent --showhost

Данная команда

создаёт переменную окружения SSLKEYLOGFILE. В ней указывается путь до файла, где MitmProxy будет сохранять сеансовые ключи.
Указывается прозрачный режим работы.

Затем файл sslkeylogfile.txt может быть использован в настройке Wireshark для расшифровки TLS трафика. Подробнее смотри в упомянутом посте.

Настройка клиента

Однако совсем без настройки клиента не получится. Для того чтобы клиент мог продолжать шифровать трафик ему нужно добавить сертификат MitmProxy в доверенные центры сертификации (CA). Потому что MitmProxy будет налету подписывать все сайты, к которым обращается клиент, своим сертификатом. И клиенту нужно доверять сертификату MitmProxy, иначе подключение к серверу будет запрещено из-за недоваренного сертификата.

Источник