Постквантовий TLS і SSH: що ввімкнути на сервері

Навіщо вмикати постквантовий обмін ключами вже зараз

Тому що трафік можна записати сьогодні й розшифрувати пізніше, коли з’явиться достатньо потужний квантовий комп’ютер. Це називають «store now, decrypt later». Захищає від такого сценарію лише обмін ключами, стійкий до квантових атак, і ввімкнути його на сервері можна вже зараз — і для TLS, і для SSH.

Загрозу названо прямо в нотатках до OpenSSH 10.1: попередження про непостквантовий обмін додано через ризик атак «store now, decrypt later». Підписи та сертифікати — окрема тема, тут про них не говоримо.

Що таке X25519MLKEM768 і що визначає RFC 10024

X25519MLKEM768 — гібридний обмін ключами для TLS 1.3: він поєднує класичний X25519 з постквантовим ML-KEM. Описаний у RFC 10024 (Standards Track, серпень 2026). Сесію захищають обидва механізми одночасно.

Важлива деталь: RFC 10024 визначає три гібриди, а не один — X25519MLKEM768, SecP256r1MLKEM768 і SecP384r1MLKEM1024. Кожен поєднує ML-KEM з обміном ECDHE. Назву пишіть точно: за нею групу задають у налаштуваннях. Стара чорнова назва X25519Kyber768Draft00 застаріла й несумісна з нинішньою.

Що потрібно для TLS: версії та перевірка

Для TLS потрібне одне: щоб вебсервер був зібраний з OpenSSL 3.5.0 або новішим. У nginx власної мінімальної версії для постквантового обміну немає — усе визначає версія OpenSSL, з якою його зібрано. Браузери, судячи з їхніх публікацій, пропонують гібрид самі, тому чекати потрібно лише від сервера.

openssl version
nginx -V 2>&1 | grep -i "built with"

Перша команда показує версію OpenSSL у системі, друга — з якою версією зібрано nginx. Якщо версія нижча за 3.5.0, постквантові групи недоступні, і потрібна інша збірка. Як читати сам сертифікат — у статті про перевірку SSL-сертифіката.

Як увімкнути постквантовий TLS у nginx

Якщо nginx зібрано з OpenSSL 3.5.0 або новішим, найчастіше нічого змінювати не потрібно: директива ssl_ecdh_curve за замовчуванням дорівнює auto, тобто береться список OpenSSL, а він віддає перевагу гібридним групам. Якщо потрібен явний список, його задають одним рядком.

Застереження: висновок про auto — наслідок із нотаток OpenSSL і документації nginx, прямої фрази там немає. Перевіряйте на своїй збірці.

1. Переконайтеся, що nginx зібрано з OpenSSL 3.5.0 або новішим.
2. Залиште директиву за замовчуванням або додайте рядок із прикладу в блок http чи server.
3. Перевірте конфігурацію через nginx -t — вона покаже, чи прийняв OpenSSL ім’я групи — і перезавантажте службу.
4. Перевірте з клієнта, що узгоджено гібридну групу.

# nginx.conf, блок http або server
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# у терміналі
nginx -t && systemctl reload nginx
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null

У списку залишено класичні X25519 і prime256v1: клієнти без постквантової підтримки узгодять їх. Якщо сервер не підтримує гібридну групу, рукостискання з такою командою завершиться помилкою — це і є перевірка. У виводі шукайте рядок Negotiated TLS1.3 group або Server Temp Key. Решта директив — у статті про налаштування SSL/TLS у nginx.

SSH: з якої версії OpenSSH що працює

Постквантовий обмін з’являвся в OpenSSH у два етапи, і їх не можна змішувати. У 9.9 алгоритм mlkem768x25519-sha256 став доступним за замовчуванням, а використовуватися за замовчуванням почав лише в 10.0. Якщо у вас версія 10.0 або новіша, нічого вмикати не потрібно.

Якщо сервер не пропонує жодного постквантового алгоритму, попередження побачать усі клієнти 10.1 і новіші. За відомостями на сторінці openssh.com/pq.html, правильне рішення — оновити сервер до реалізації SSH, де є хоча б один такий алгоритм.

Як увімкнути й перевірити постквантовий обмін у SSH

Перевірка — кілька команд: версія клієнта, список підтримуваних обмінів і обраний обмін у докладному виводі; на сервері підсумок показує sshd -T. На версії 10.0 і новіших вмикати нічого не потрібно, якщо ви не перевизначили список вручну.

ssh -V
ssh -Q kex | grep -E "mlkem|sntrup"
sshd -T | grep -i kexalgorithms
ssh -v user@server.example 2>&1 | grep -i "kex: algorithm"

Явний порядок у sshd_config задають рядком KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256. Перед перезавантаженням перевірте конфігурацію через sshd -t і тримайте другу сесію відкритою. Решта налаштувань демона — у статті про захист SSH-сервера.

Застереження: що може піти не так

Головна пастка — залишити в налаштуванні лише постквантові алгоритми. Тоді клієнти, які їх не знають, перестануть підключатися. Це наслідок того, як узгоджуються алгоритми, а не цитата з документації. Тому класичний запасний варіант зі списку не прибирають, доки не переконалися, що всі ваші клієнти свіжі.

Якщо перед сервером стоїть проксі, балансувальник або CDN, групу узгоджує той вузол, який завершує TLS.

Часті запитання

Чи потрібно змінювати сертифікат заради постквантового TLS?

Ні. Обмін ключами й сертифікат — різні частини рукостискання. Гібрид X25519MLKEM768 змінює перше, а сертифікат лишається колишнім.

Чому ssh пише, що з’єднання не постквантове?

Так поводиться OpenSSH з версії 10.1, коли узгоджено непостквантовий обмін; опція WarnWeakCrypto увімкнена за замовчуванням. Причину шукайте на сервері: оновіть його, а не глушіть попередження.

Що робити клієнтам ZevsHost?

На спільному хостингу версію OpenSSL і налаштування TLS задає сервер провайдера, і постквантовий обмін там увімкнути неможливо — це не в руках клієнта. Власне рішення ви ухвалюєте на VPS і виділеному сервері, де версії OpenSSL, nginx та OpenSSH ваші: з них і починайте перевірку.