Безопасность
PFS — Perfect Forward Secrecy
Свойство криптопротокола: компрометация долговременного ключа не раскрывает прошлые сессии. Обязательная характеристика современного VPN.
Определение
Perfect Forward Secrecy (PFS, идеальная прямая секретность) — свойство криптопротокола, при котором компрометация долговременных секретных ключей не позволяет дешифровать ранее перехваченные сессии. Каждая сессия использует свой эфемерный ключ, который уничтожается после её завершения.
Термин ввёл Whitfield Diffie с коллегами в 1992 году. Современный стандарт TLS 1.3 — PFS обязательна; OpenVPN, WireGuard, IKEv2 — все используют PFS-варианты обмена ключами.
Зачем нужна
Сценарий атаки без PFS:
- Государство/провайдер пишет весь TLS-трафик к сайту X за 5 лет (любые трафик-граберы умеют делать).
- Через 5 лет — взлом, утечка, повестка, или вскрыли админа сервера. Получают private key TLS-сертификата.
- Этим private key дешифруют все 5 лет архивированного трафика.
С PFS такая атака невозможна. Долговременный ключ сертификата не участвует в шифровании сессии напрямую — он только для аутентификации сервера. Сами session-keys генерируются эфемерным Diffie-Hellman’ом (DHE/ECDHE), и после завершения сессии оба участника их забывают.
Как работает технически
В TLS 1.3 при handshake:
- Клиент генерирует временную пару Diffie-Hellman (приватный + публичный ephemeral key).
- Сервер делает то же самое.
- Они обмениваются публичными частями.
- Каждый вычисляет общий секрет из своего приватного + чужого публичного. Это сессионный ключ.
- После сессии оба эфемерных приватных ключа удаляются.
Долговременный сертификат сервера используется только чтобы подписать своё ephemeral-public-key и доказать клиенту, что это именно тот сервер, к которому он подключился. Сам он в шифровании session-данных не участвует.
Где PFS обязательна
| Протокол | PFS | Как достигается |
|---|---|---|
| TLS 1.3 | Да, обязательно | ECDHE по дефолту |
| TLS 1.2 c ECDHE | Да | Cipher suites вида ECDHE-* |
| TLS 1.2 c RSA | Нет | Master secret приходит зашифрованным RSA-ключом сервера |
| WireGuard | Да | Noise framework + ephemeral DH каждые 2 минуты |
| OpenVPN | Да с tls-cipher TLS-ECDHE-* | Зависит от конфига |
| IKEv2/IPsec | Да с PFS-группой в Phase 2 | Зависит от конфига |
| SSH | Да с современными KEX | curve25519-sha256, ecdh-sha2-* |
Ловушка: «using TLS 1.2 with RSA key exchange» = no PFS. До 2018 года это было нормой; сейчас deprecated, но в legacy-системах ещё встречается.
PFS в WireGuard
WireGuard делает PFS по особенному: каждые 2 минуты автоматически обновляет ephemeral key (re-key handshake). Если кто-то скомпрометирует один ключ, его «окно полезности» — максимум 2 минуты прошлого трафика.
Что PFS НЕ делает
- Не защищает от MITM на этапе handshake. Если CA в браузере скомпрометирован, перехватчик может выпустить «настоящий» сертификат и сделать MITM — но это компрометация в момент атаки, не прошлого трафика.
- Не защищает от компрометации эндпоинтов. Если у вас на компе кейлоггер, никакой PFS не поможет.
- Не защищает от метаданных. PFS шифрует содержимое, но не факт соединения, тайминги, размеры пакетов.
Источники
- RFC 8446 §4.2.8 — TLS 1.3 key-share.
- Whitfield Diffie, Paul Van Oorschot, Michael Wiener — «Authentication and authenticated key exchanges» (1992).
Связанные термины
- TLS 1.3 — где PFS встроена.
- WireGuard — PFS в VPN-протоколе.
- AES-256-GCM — шифр, защищаемый PFS-ключом.