Forward Secrecy в VPN — практическое применение PFS

Определение

Forward Secrecy в контексте VPN — конкретная реализация общего свойства PFS внутри VPN-протоколов через регулярное обновление эфемерных session-ключей. Если общий PFS — это теоретическое свойство криптопротокола, то FS в VPN — практический набор настроек: периодичность re-key handshake, размер windows, что входит в долговременный материал, что в эфемерный.

Часто термины используют взаимозаменяемо, но в VPN-конфигах разница между «PFS включён в принципе» и «PFS правильно настроен на эту сессию» — критична. Долгая сессия с одним set’ом ключей теряет FS на практике, даже если протокол его «формально» обеспечивает.

Как разные VPN-протоколы реализуют FS

WireGuard

• Re-key каждые 2 минуты (REJECT_AFTER_TIME = 180s, новый handshake запускается в 120s).
• Curve25519 ECDH для генерации session-keys.
• Ephemeral material: на каждом handshake обе стороны генерируют новую пару ключей, используют её один раз, удаляют.
• PSK (опционально): для постквантовой защиты (см. WireGuard-PQ) — не нарушает FS.

WireGuard — эталон FS в VPN: окно компрометации одного session-key max 2 минуты.

OpenVPN

• Re-key через reneg-sec (default 3600 = 1 час). Можно поставить 600 (10 мин) или ниже.
• Cipher suite должна включать ECDHE для FS. --tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 — пример с FS.
• Anti-pattern: --tls-cipher TLS-RSA-WITH-* — нет FS, master secret шифруется RSA-ключом сервера.

В современных OpenVPN-конфигах FS работает, но требует явной настройки cipher.

IKEv2/IPsec

• Phase 1 (IKE): ECDHE по умолчанию в IKEv2 — FS обеспечен.
• Phase 2 (ESP/AH SA-renegotiation): PFS-группа должна быть включена явно (pfs=yes в strongswan, dh-group в Phase 2 предложениях).
• Anti-pattern: Phase 2 без PFS — IKE передаёт обновлённый session-key зашифрованным теми же IKE-ключами. Компрометация IKE-key даёт доступ ко всем последующим Phase 2 SA.

TLS-based (TLS-in-TLS, Shadowsocks-2022)

• TLS 1.3 — FS обязательна.
• TLS 1.2 с ECDHE — FS есть.
• TLS 1.2 без ECDHE (RSA-only) — FS НЕТ.

Reality / VLESS

• Лежат поверх TLS 1.3 → автоматически FS.
• Re-key — стандартный TLS re-handshake.

Какой re-key интервал правильный

Trade-off:

• Короткий интервал (1-5 мин): меньше компрометируется при leak одного ключа. Больше CPU/network overhead на handshakes.
• Длинный интервал (1 час+): больше трафика под одним ключом — больше потенциальный урон.

Современные best-practices:

• WireGuard: 2 минуты (default, не менять).
• OpenVPN: 10-60 минут (reneg-sec 600 или 3600).
• IPsec Phase 2: 1 час (default).
• TLS-in-TLS: re-key в TLS-stack сам по себе, обычно 24 часа или session-resumption.

Угрозы, которые FS закрывает

• Harvest-now-decrypt-later: даже если через 10 лет квантовый компьютер расшифрует Curve25519 (один handshake), он сломает один сессионный ключ (один re-key window). Сейчас все WG-юзеры с PSK (PQ-mode) защищены.
• Server key leak: ключ сервера утёк/изъят → все будущие сессии могут быть MITM’нуты, но прошлые архивы — нет.
• Long-term archive analysis: state actor пишет VPN-трафик в архив. Через N лет — попытка дешифровать. Без FS — успех. С FS — нет.

Угрозы, которые FS НЕ закрывает

• Compromise during session: если ключ ваш утёк во время активной сессии — текущее окно уязвимо.
• Side-channel attacks: timing, fault injection, RowHammer — обходят FS на уровне реализации.
• Endpoint compromise: вирус на клиенте/сервере читает plaintext до шифрования.

В России 2026

FS не помогает с цензурой напрямую (это про шифрование, не маскировку). Но косвенно: если ТСПУ когда-нибудь начнёт массовый сбор VPN-трафика в архив — FS не даст этот архив расшифровать post-factum.

Источники

• WireGuard whitepaper §5.4.4 — re-key timing.
• OpenVPN docs — TLS rekey.
• RFC 7296 (IKEv2) §1.3.1 — rekey механика.

Связанные термины

• PFS — общее свойство.
• WireGuard — эталон FS в VPN.
• OpenVPN — настройки FS.
• IKEv2 — Phase 2 PFS-группа.
• TLS 1.3 — основа FS в TLS-based VPN.