Perfect Forward Secrecy: защита прошлых сеансов при утечке ключа

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

Perfect Forward Secrecy, совершенная прямая секретность, устраняет такую возможность. Даже полная утечка долговременного ключа не помогает раскрыть уже завершённые сеансы, потому что каждый из них использовал собственный одноразовый ключ, который нигде не сохранился.

Основа — эфемерный обмен ключами. При каждом соединении клиент и сервер генерируют временные пары ключей и с их помощью договариваются об общем секрете по схеме Диффи-Хеллмана. Общий секрет получается математически на обеих сторонах, но по сети не передаётся. Долговременный ключ сервера участвует лишь в подписи, подтверждающей, что вы говорите с настоящим сервером, а не в защите самого секрета.

После завершения сеанса временные значения удаляются из памяти. Восстановить их по записанному трафику нельзя, а долговременный ключ их не содержит. Отсюда и слово «прямая»: секретность распространяется на прошлое. Сам обмен разобран в материале о протоколе Диффи-Хеллмана.

В TLS 1.3 прямая секретность обязательна: устаревший обмен ключами через шифрование сессионного секрета открытым ключом RSA там убран, остались только эфемерные схемы на основе Диффи-Хеллмана. В TLS 1.2 всё зависит от выбранного набора алгоритмов: наборы с ECDHE или DHE обеспечивают PFS, а наборы с обменом через RSA — нет.

Поэтому при настройке сервера в старых версиях протокола предпочтительные наборы алгоритмов ставят с ECDHE. Подробно набор описывает страница о cipher suite. Ту же идею применяют мессенджеры и другие защищённые каналы связи: ключи периодически обновляются, чтобы утечка одного не открывала остальные.

Прямая секретность не всесильна. Она не защитит, если злоумышленник получил доступ к серверу в тот момент, пока сеанс ещё идёт, и может прочитать ключи из памяти. Она не спасёт при заражении устройства или при перехвате данных до шифрования.

Есть тонкость с возобновлением сеансов. Механизм билетов сессий позволяет быстро восстановить соединение, но если ключ шифрования билетов долго не меняют, он фактически превращается в долговременный секрет и подрывает PFS. Хорошая настройка ротирует такие ключи часто, например ежедневно.

Ещё один вопрос — квантовые компьютеры. Записанный сегодня трафик когда-нибудь можно расшифровать, если алгоритм обмена окажется уязвим. Об этом говорится в статье о постквантовой криптографии.

Откройте сведения о защищённом соединении в браузере: в Chrome и Firefox в инструментах разработчика на вкладке безопасности указан обмен ключами, например X25519 или ECDHE. Для проверки сервера подойдёт openssl s_client -connect имя:443, в выводе будет строка про temporary key или server temp key. Если она есть, обмен эфемерный.

Онлайн-сканеры настройки TLS показывают, все ли наборы алгоритмов обеспечивают прямую секретность. Администратору полезно отключить наборы без PFS в TLS 1.2 и убедиться, что TLS 1.3 включён. О различиях версий протокола подробнее в статье про TLS 1.3.

Практический вывод для владельца сервера прост. Убедитесь, что включён TLS 1.3, а в TLS 1.2 остались только наборы с ECDHE или DHE. Если используете DHE, применяйте достаточно большие группы, не менее 2048 бит, а лучше стандартные именованные группы. Отключите или часто меняйте ключи билетов сессий и не храните их на диске. Настройка проверяется сканером за минуту, а выигрыш существенный: даже если ключ сервера когда-нибудь окажется у третьих лиц, содержимое старых сеансов останется закрытым.