Постквантова міграція: що перевірити у сертифікатах і підписах

Коли криптографія стає операційною задачею

Команда рідко оновлює сертифікати й TLS-налаштування заради самої криптографії. Зазвичай причина простіша: одного дня старий клієнт, проксі, бібліотека або центр сертифікації стає вузьким місцем усієї системи. Постквантова міграція схожа саме на таку задачу. Вона не починається з формул, а починається з питання: хто саме встановлює HTTPS-з’єднання з вашим сервісом і що станеться, якщо правила цього з’єднання зміняться.

Сьогодні RSA та еліптичні криві залишаються основою більшості реальних HTTPS-систем. Проблема в тому, що достатньо потужні квантові комп’ютери можуть змінити модель безпеки для цих алгоритмів. Це не означає, що завтра всі сертифікати перестануть працювати. Але це означає, що інфраструктуру треба готувати завчасно: TLS, сертифікатний ланцюг, клієнтські бібліотеки, проксі та спостереження за помилками не оновлюються за один день.

Спершу намалюйте карту HTTPS-ланцюга

Перший крок не має бути героїчним. Візьміть один сервіс і намалюйте його шлях від клієнта до застосунку. Позначте браузери, мобільні застосунки, серверні інтеграції, внутрішні скрипти, старі пристрої. Далі позначте CDN, балансувальник, ingress, reverse proxy, service mesh або сам застосунок, якщо TLS-термінація відбувається там.

Окремо випишіть сертифікатний ланцюг: хто випускає сертифікат, як він оновлюється, де лежать приватні ключі, хто контролює проміжні сертифікати, які середовища використовують ті самі або різні налаштування. Для невеликої команди це вже може відкрити неприємні деталі: один сервіс оновлюється через автоматизацію, інший вручну; частина клієнтів використовує системне сховище довіри, а частина має зашитий старий набір сертифікатів.

Постквантові зміни зачеплять саме ці межі. Якщо ви не знаєте, де завершується TLS і хто перевіряє цифровий підпис, ви не зможете безпечно тестувати ML-KEM або ML-DSA.

ML-KEM і ML-DSA не роблять одну й ту саму роботу

У постквантовій розмові легко змішати всі назви в один список. Для операційного плану важливо розділити дві задачі. ML-KEM стосується узгодження секрету для сеансу. У TLS це частина, яка допомагає сторонам отримати спільний матеріал для шифрування конкретного з’єднання. Саме тут індустрія вже активніше рухається до гібридних підходів, де новий механізм поєднується зі старим, щоб не ламати сумісність.

ML-DSA стосується цифрових підписів. Підписи потрібні, щоб клієнт міг перевірити сертифікат, а система могла довіряти походженню даних. Це інша ділянка ланцюга. Якщо обмін ключами можна тестувати поступово на рівні сеансів, то підписи тісно пов’язані з сертифікатами, центрами сертифікації, сховищами довіри та перевіркою на клієнтському боці.

Тому питання звучить не просто як увімкнути ML-DSA. Практичніше питати так: які клієнти зможуть перевірити такий підпис, які бібліотеки це підтримують, як зміниться розмір сертифікатного ланцюга, чи витримає це ваш проксі, журналювання й моніторинг.

Чому підписи складніші в експлуатації

ML-DSA важливий, бо стандартизований і доступний для впровадження. Але він не є невидимою заміною для старих підписів. Постквантові підписи мають інші розміри ключів і підписів, інший профіль продуктивності та інші наслідки для мережі. У масштабі великого edge-провайдера це перетворюється на трафік, пам’ять і мільйони перевірок. У масштабі невеликої команди це може проявитися як повільніший початок з’єднання, несподівані помилки в старому клієнті або обмеження в бібліотеці, про яку давно забули.

Окрема складність у тому, що сертифікати живуть у ширшій екосистемі. Ваш сервер може бути готовий, але клієнтська операційна система ні. Бібліотека може підтримувати новий алгоритм, але проміжний проксі може не пропустити більший ланцюг. Тестовий сценарій у сучасному браузері може пройти, а стара серверна інтеграція партнера впаде без зрозумілого повідомлення.

Саме тому чекати ідеального майбутнього алгоритму теж ризиковано. Краще вже зараз навчитися бачити залежності, вимірювати витрати й планувати відкат. ML-DSA може бути не найзручнішим для кожного випадку, але він є частиною реального стандартизованого шляху.

Малий план тестування для тестового середовища

Почніть із базової лінії. Виміряйте час встановлення TLS-з’єднання, розмір переданих даних під час рукостискання, частку помилок, типові версії клієнтів і бібліотек. Без цих даних будь-який тест буде схожий на враження, а не на інженерне рішення.

Далі створіть окремий тестовий маршрут. Не вимикайте чинні алгоритми для всіх. Перевірте, чи ваша TLS-бібліотека, проксі або балансувальник взагалі мають підтримку потрібних експериментальних чи стандартизованих режимів. Для ML-KEM звертайте увагу на гібридні варіанти. Для ML-DSA перевіряйте не тільки сервер, а й весь сертифікатний ланцюг і клієнтську перевірку.

Складіть матрицю клієнтів: останні браузери, мобільні версії, внутрішні сервіси, партнерські інтеграції, скрипти автоматизації. Для кожного запишіть результат: з’єднання успішне, помилка перевірки сертифіката, тайм-аут, незрозуміла TLS-помилка, падіння бібліотеки. Це нудна таблиця, але саме вона перетворює постквантову міграцію з абстракції на план.

Антипатерни, які варто зупинити

Перший антипатерн — оновити одну бібліотеку й вважати задачу завершеною. TLS проходить через кілька шарів, і кожен шар може змінити поведінку.

Другий — тестувати лише сучасний браузер. Ваш найризикованіший клієнт часто не браузер, а стара серверна інтеграція, мобільний застосунок без оновлень або внутрішній агент на застарілій системі.

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

Четвертий — ставитися до ML-DSA як до перемикача постачальника. Це не лише функція CDN або хмарної платформи. Вам все одно треба знати, хто перевіряє сертифікати, які обмеження має клієнт і де ви побачите помилку.

Що можна відкласти

Не потрібно завтра переносити весь внутрішній центр сертифікації на постквантові підписи. Не потрібно прибирати RSA або ECDSA без широкої підтримки клієнтів. Не потрібно оптимізувати розміри й продуктивність до того, як ви побачили власні вимірювання.

Але не варто відкладати інвентаризацію. Карта TLS-термінації, список клієнтів, список бібліотек, базові метрики та тестове середовище — це робота, яка корисна вже зараз. Вона допоможе не тільки з ML-KEM і ML-DSA, а й з будь-якою майбутньою зміною в HTTPS.

Джерела

• Cloudflare: https://blog.cloudflare.com/ml-dsa-will-have-to-do/
• NIST FIPS 203, ML-KEM: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, ML-DSA: https://csrc.nist.gov/pubs/fips/204/final
• IETF RFC 8446, TLS 1.3: https://www.rfc-editor.org/rfc/rfc8446