Можно ли расшифровать трафик TLS при прослушивании
Что проверяют
Понимаете ли вы, от чего защищает TLS и где его границы: пассивный перехват против активного вмешательства, ключ сервера против сеансовых ключей. Следом обычно спрашивают, как вы сами смотрели бы HTTPS-трафик своего Java-сервиса при отладке.
Как отвечать
Пассивно, просто записав трафик, современный TLS не расшифровать. Дальше важны детали:
- TLS 1.3: ключ сессии вырабатывается через эфемерный (EC)DHE, поэтому действует прямая секретность. Даже украденный позже закрытый ключ сервера не раскроет записанный ранее трафик;
- TLS 1.2 с обменом ключами RSA: здесь закрытый ключ сервера позволяет расшифровать запись задним числом, Wireshark это умеет. Поэтому такие наборы шифров и убрали из 1.3;
- активный MitM: прокси вроде mitmproxy, Charles или Burp подставляет свой сертификат. Работает, только если клиент доверяет его CA, то есть кто-то добавил этот CA в truststore;
- метаданные: без расшифровки видны IP-адреса, объёмы, тайминги и имя хоста в SNI, если не включён ECH.
Для отладки в Java есть легальные пути. -Djavax.net.debug=ssl:handshake печатает ход рукопожатия, версию протокола и выбранный набор шифров. Чтобы увидеть содержимое, приложение запускают через прокси, а его CA добавляют в отдельный truststore через keytool и подключают -Djavax.net.ssl.trustStore. Для Wireshark нужен лог сеансовых ключей в формате SSLKEYLOGFILE: браузеры и curl пишут его сами, для JVM обычно подключают java-агент, который выгружает ключи.
Покажите и обратную сторону: если приложение закрепляет сертификат (pinning), прокси не пройдёт, и это нормальное поведение.
Где спотыкаются
Пишут TrustManager, который доверяет всем, чтобы прокси заработал, и забывают его в коде. Так в прод попадает клиент, принимающий любой сертификат.
Считают, что закрытого ключа сервера достаточно для расшифровки любого записанного трафика. Для TLS 1.3 и для ECDHE в 1.2 это не так.
Говорят, что TLS прячет всё. Имя сайта в SNI и характер трафика видны, пока не включён ECH.