Pierwszy krok postkwantowy, którego CDN nie zrobi za was
Inżynier, który otwiera stronę stanu postkwantowego Cloudflare, od trzech lat czyta tam dobre wiadomości, nie robiąc nic. Na odcinku między przeglądarką odwiedzającego a brzegiem sieci Cloudflare szyfrowanie postkwantowe działa domyślnie od 2023 roku, z hybrydowym uzgadnianiem kluczy zapisywanym dziś jako X25519MLKEM768, i żaden klient go nie konfigurował. Przyszło tak, jak przychodzi pogoda.
Dwudziestego dziewiątego lipca ta forma pracy się skończyła. Cloudflare ogłosił uwierzytelnianie postkwantowe na drugim odcinku, między swoją siecią a serwerami origin prowadzonymi przez klientów, z podpisami ML-DSA. Uwierzytelnienia pośrednik nie załatwi w waszym imieniu, bo tym, co zostaje poświadczone, jest wasz serwer. Aby z niego skorzystać, ten serwer musi przechowywać i okazywać certyfikat podpisany algorytmem, którego zapewne nigdy nie widział.
Co zostało faktycznie dostarczone
Zmianę niosą dwa produkty. Authenticated Origin Pulls to mechanizm, w którym Cloudflare okazuje waszemu serwerowi origin certyfikat klienta, żeby ten mógł odrzucać połączenia, które nie przeszły przez Cloudflare, i przyjmuje teraz ML-DSA na poziomach konfiguracji dla strefy i dla nazwy hosta. Poziom globalny opisano jako mający pojawić się później. Custom Origin Trust Store, który pozwala klientowi wgrać własne urzędy certyfikacji zamiast polegać na zestawie publicznym, przyjmuje odtąd urzędy podpisujące algorytmem ML-DSA, dzięki czemu certyfikat origin można zweryfikować wobec podpisującego postkwantowego.
Obsługiwane są wszystkie trzy zestawy parametrów z FIPS 204: ML-DSA-44, ML-DSA-65 oraz ML-DSA-87. Uzgadnianie kluczy w połączeniu pozostaje hybrydowe, w postaci X25519MLKEM768. Innymi słowy poufność na tym odcinku była już załatwiona; zmieniła się ta część, która dowodzi, kto siedzi na każdym z końców.
Pięć rzeczy, które muszą się zmienić na waszej własnej maszynie
Lista wymagań jest krótka, a każdy punkt spada na waszą stronę połączenia. Na serwerze origin potrzebny jest OpenSSL 3.5.0 lub nowszy, choćby po to, żeby w ogóle wytworzyć łańcuch certyfikatów ML-DSA. Certyfikat trzeba wgrać w kodowaniu opartym wyłącznie na ziarnie, które definiuje FIPS 204, a nie jest to kodowanie, jakie większość narzędzi wypuszcza z przyzwyczajenia. Serwer WWW na origin, w przykładzie samego Cloudflare NGINX, trzeba skonfigurować tak, aby albo okazywał certyfikat ML-DSA, albo weryfikował wobec niego certyfikat klienta. Kto używa Custom Origin Trust Store, musi ustawić tryb SSL/TLS strefy na Full (strict). A zaufanie do mechanizmu podatnego na komputery kwantowe trzeba potem usunąć, bo pozostawienie go pozwala napastnikowi wynegocjować starą drogę i czyni nową wyłącznie ozdobą.
Nic z tego nie jest egzotyczne. OpenSSL 3.5.0 ukazał się 8 kwietnia 2025 roku jako linia o wydłużonym wsparciu, z aktualizacjami do kwietnia 2030 roku, i było to pierwsze wydanie niosące wbudowane trzy postkwantowe standardy NIST. Trudność nie leży w numerze wersji. Leży w tym, że origin bywa najrzadziej odwiedzaną maszyną w całym parku serwerowym: urządzeniem, skrzynką pod opieką dostawcy, maszyną wirtualną, której nikt nie przebudował od chwili utworzenia, albo modułem równoważenia obciążenia, którego warstwa TLS jest problemem kogoś innego dopóty, dopóki nim być nie przestanie.
Wdrożenie samego Cloudflare jest argumentem za etapem testowym. Dziesiątego czerwca 2026 roku firma zaliczyła awarię produkcyjną w trakcie tej właśnie dystrybucji, wywołaną kontrolą pola KeyUsage w certyfikatach. To szczegół rozszerzenia certyfikatu, a trafił zespół, który zawodowo buduje biblioteki TLS, na infrastrukturze kontrolowanej od początku do końca. Średniej wielkości firma robiąca tę samą zmianę w czwartkowe popołudnie powinna założyć, że znajdzie coś podobnego.
Dlaczego zalecany zestaw jest tym najmniejszym
Cloudflare zaleca ML-DSA-44 do większości zastosowań i opisuje go jako opcję najwydajniejszą. To broniący się wybór techniczny, a zarazem najmniejszy z trzech zestawów z FIPS 204, umieszczony w kategorii bezpieczeństwa 2 według NIST. Powszechniejsze zalecenie domyślne gdzie indziej brzmi ML-DSA-65, kategoria 3. Podpisy postkwantowe są duże w porównaniu z tymi, które zastępują, a na odcinku niosącym każde pojedyncze żądanie między brzegiem sieci a origin różnica rozmiaru jest realnym kosztem opóźnienia i pasma, nie zaś teoretycznym.
Dla właściciela liczy się to, że powstaje tutaj decyzja z waszym nazwiskiem. Jeśli wasza polityka bezpieczeństwa albo audytor już przyjęli kategorię 3 przy podpisywaniu, ciche przejęcie zalecenia dostawcy CDN tworzy wyjątek, który trzeba będzie później wytłumaczyć. Zapiszcie zestaw parametrów wraz z uzasadnieniem, zanim ktoś inny wychwyci rozbieżność podczas przeglądu.
Termin, który jest prawdziwy, i ten, który nim nie jest
Bądźcie precyzyjni co do pilności, bo dwie połowy postkwantowej ochrony naprawdę chodzą według różnych zegarów. Zaszyfrowany ruch nagrany dzisiaj może zostać odszyfrowany przez przyszłą maszynę i właśnie to czyni z uzgadniania kluczy problem teraźniejszy. Podpisu nie da się sfałszować wstecz w ten sam sposób: nikt nie użyje komputera kwantowego w 2032 roku, żeby z mocą wsteczną wymyślić uścisk dłoni z dzisiejszego ranka. Powodem, by zacząć teraz, nie jest trwający atak, lecz długość kolejki stojącej za tą zmianą, która biegnie przez urzędy certyfikacji, sprzęt, urządzenia dostawców i każdy origin, o którym zdążyliście zapomnieć.
Cloudflare opatrzył własną kolejkę datami: pełne zabezpieczenie postkwantowe we wszystkich produktach do 2029 roku oraz pierwsze wdrożenie Merkle Tree Certificates po stronie odwiedzającego z celem na 2027 rok. To terminy tej firmy, nie wasze. Wasz to najbliższy przegląd, który zapyta, co chroni połączenie między waszym CDN a waszymi serwerami, a w Polsce punktem odniesienia jest tutaj NASK. Uczciwa odpowiedź brzmi dziś dla niemal wszystkich: klasyczna kryptografia, z obsługiwanym następcą stojącym obok bez użycia.
Czytaj dalej: Kilku operatorów nie znaczy, że ty wybierasz ścieżkę | Domeny Albanii zgasły. Niemieckie zgasły w maju.



