Навіщо Cloudflare додала постквантовий підпис між CDN і сервером

постквантовий захистсертифікати TLSCloudflare

Ноутбук і три мережеві вузли показують два захищені з’єднання між браузером, CDN і сервером сайту

Браузер не завжди підключається прямо до сайту

Коли ви відкриваєте сайт через Cloudflare або іншу мережу доставки контенту (CDN), запит часто проходить три точки:

  1. браузер користувача;
  2. проміжний вузол Cloudflare;
  3. справжній сервер, де працює сайт.

Cloudflare може відфільтрувати атаку, віддати збережену копію сторінки або переслати запит далі. Тому на маршруті зазвичай є два окремі з’єднання: браузер → Cloudflare і Cloudflare → сервер сайту.

Значок HTTPS у браузері підтверджує захищене з’єднання з Cloudflare. Але він нічого не розповідає користувачеві про другу ділянку. Якщо вона теж використовує HTTPS, Cloudflare окремо перевіряє сертифікат сервера сайту.

Саме для цієї перевірки Cloudflare додала підтримку постквантових цифрових підписів ML-DSA.

Що саме змінила Cloudflare

29 липня 2026 року Cloudflare оголосила, що два її механізми можуть працювати із сертифікатами та підписами ML-DSA.

  • Custom Origin Trust Store дає Cloudflare власний список центрів сертифікації, яким можна довіряти під час перевірки сервера сайту.
  • Authenticated Origin Pulls працює у зворотному напрямку: сервер сайту перевіряє сертифікат, який показує Cloudflare.

Другий варіант називають взаємним TLS: не лише Cloudflare перевіряє сервер, а й сервер перевіряє Cloudflare. Це допомагає не приймати прямі підключення від сторонніх клієнтів.

Новина стосується саме перевірки справжності сторін з’єднання. Вона не означає, що весь інтернет-трафік Cloudflare вже став постквантовим.

Що таке ML-DSA простими словами

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

ML-DSA — новий стандарт цифрового підпису, описаний у FIPS 204. Його створили так, щоб відомі підходи з використанням потужного квантового комп’ютера не ламали підпис.

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

Навіщо випробовувати це зараз

Масові квантові атаки на TLS не відбуваються сьогодні. Сенс раннього тестування інший: перевірити, чи готові сервери, проксі, бібліотеки й засоби випуску сертифікатів до нового формату.

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

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

Що може зламатися

Навіть якщо Cloudflare підтримує ML-DSA, інша частина маршруту може бути не готова:

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

Тому читання файла сертифіката — ще не перевірка. Потрібно створити нове з’єднання й побачити, який алгоритм справді використано.

Як провести безпечний пілот

Підготуйте тест

  1. Намалюйте маршрут. Окремо позначте з’єднання браузера з CDN і CDN із сервером. Запишіть, хто перевіряє чий сертифікат.
  2. Виділіть тестовий домен. Не починайте з усього виробничого трафіку.
  3. Перевірте успішний сценарій. Нове з’єднання має використати очікуваний сертифікат, ланцюг довіри та ML-DSA.
  4. Навмисно створіть помилки. Система має правильно відхилити недовірений, прострочений або виданий для іншого імені сертифікат.

Виміряйте результат

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

Чого не варто висновувати

Підтримка ML-DSA між Cloudflare і сервером не змінює автоматично з’єднання між браузером і Cloudflare. Вона також не доводить, що весь TLS став стійким до квантових атак.

Це один конкретний крок: новий спосіб перевірити справжність сервера або клієнта на окремій ділянці. Його користь сьогодні — не в терміновій масовій міграції, а в спокійній перевірці сумісності до того, як нові алгоритми стануть повсякденними.

Джерела

Короткий чеклист

  • намалювати окремо з’єднання браузера з CDN і CDN із сервером
  • перевірити, хто та за якими правилами перевіряє сертифікат
  • випробувати правильний, прострочений і недовірений сертифікати
  • порівняти помилки, затримку й навантаження до та після зміни
  • почати з тестового домену та перевірити відкат новим з’єднанням

Перевірити постквантовий підпис між CDN і сервером

Допоможи підготувати безпечну перевірку постквантового підпису між CDN і сервером сайту. Вхідні дані: - схема шляху від браузера через CDN до сервера; - місця, де завершуються захищені TLS-з’єднання; - проксі, балансувальники, сервери та криптографічні бібліотеки; - чинні сертифікати й сховища довіри; - тестовий домен, базові метрики та процедура відкату. Якщо даних бракує, познач їх як НЕВІДОМО. Не вважай ML-DSA повним постквантовим захистом усього сайту. У відповіді: 1. Намалюй просту схему двох з’єднань. 2. Вкажи, хто перевіряє чий сертифікат. 3. Дай позитивний тест і щонайменше три навмисно помилкові тести. 4. Запропонуй метрики, критерії зупинки й порядок поступового ввімкнення. 5. Опиши відкат і перевірку новим з’єднанням після нього.