Wprowadzenie do problemu / definicja luki
„Quantum-safe” w kontekście HTTPS to nie jedna zmiana, tylko dwa osobne fronty migracji:
- Uzgadnianie klucza (key exchange) — chroni przed scenariuszem harvest-now/decrypt-later (zbieranie szyfrogramów dziś i odszyfrowanie w przyszłości, gdy pojawi się wystarczająco silny komputer kwantowy).
- Uwierzytelnianie (certyfikaty i podpisy) — zabezpiecza zaufanie do tożsamości serwera (czy łączysz się z adekwatną domeną) i do całego łańcucha PKI.
Pierwszy obszar da się wdrażać szybciej (software update po obu stronach). Drugi jest znacznie trudniejszy, bo klasyczny model X.509 + Certificate Transparency (CT) oznacza, iż większe klucze i podpisy zaczynają realnie „boleć” w przepustowości i opóźnieniach. Google właśnie komunikuje podejście, które ma to obejść.
W skrócie
- Google ogłosiło program w Chrome, którego celem jest doprowadzenie do kwantoodpornych certyfikatów HTTPS, ale bez natychmiastowego przejścia na „duże” certyfikaty PQC w klasycznym X.509.
- Powód: w obecnym modelu TLS + CT, certyfikaty (i dowody CT) są istotną częścią danych przesyłanych w handshake — a przy PQC skala rośnie.
- Kluczowy pomysł: Merkle Tree Certificates (MTC) — zamiast wysyłać pełne łańcuchy X.509, przeglądarka dostaje lekki dowód inkluzji w drzewie Merkle, którego „głowę” (Tree Head) podpisuje CA.
- Równolegle IETF uruchomiło grupę roboczą PLANTS, której celem jest „przycięcie kosztów” dużych podpisów post-quantum w PKI z CT i w protokołach interaktywnych typu TLS.
Kontekst / historia / powiązania
Dlaczego CT komplikuje migrację do PQ podpisów?
CT wymaga, aby certyfikaty były publicznie logowane i monitorowalne. W obecnym ekosystemie oznacza to m.in.:
- logi zawierają całe certyfikaty (a więc też klucze i podpisy),
- klient weryfikuje podpis CA i artefakty CT (np. SCT), które też niosą narzut.
Gdy podpisy post-quantum są większe, koszt rośnie:
- po stronie operatorów logów (większe wpisy),
- w handshake TLS (więcej bajtów do przesłania i przetworzenia),
- w całym ekosystemie transparentności (więcej danych do audytu).
Cloudflare zwraca uwagę, iż już dziś same łańcuchy certyfikatów potrafią stanowić znaczący udział danych w połączeniach (szczególnie w QUIC), a przy zastąpieniu podpisów klasycznych przez PQC ten koszt może gwałtownie wzrosnąć.
Analiza techniczna / szczegóły podejścia (MTC)
Klasyczne X.509: co jest „ciężkie”
W typowym TLS handshake klient dostaje:
- certyfikat serwera,
- zwykle pośrednie CA (intermediates),
- informacje/dowody CT (w zależności od mechanizmu),
- i dopiero potem weryfikuje łańcuch.
To jest wielokrotność danych i podpisów. Po dodaniu PQC rozmiary rosną jeszcze bardziej.
MTC: „certyfikat jako dowód w drzewie”
Z opisu Google (i streszczenia branżowego) wynika model:
- CA utrzymuje drzewo Merkle z ogromną liczbą „wiązań” (np. domena → klucz publiczny),
- CA podpisuje pojedynczy Tree Head reprezentujący potencjalnie miliony wpisów,
- serwer przesyła klientowi nie cały łańcuch certyfikatów, tylko krótki proof of inclusion (ścieżkę Merkle) potwierdzający, iż konkretne wiązanie jest elementem podpisanego drzewa.
To jest ważne z dwóch powodów:
- Amortyzacja podpisu: jeden podpis (Tree Head) „obsługuje” bardzo wiele certyfikatów/wpisów.
- Mniejszy narzut w handshake: klient dostaje mało danych (dowód Merkle), a nie kilobajty łańcuchów, które przy PQC stają się problematyczne.
PLANTS: standaryzacja tego kierunku
Karta grupy PLANTS wprost wskazuje cel: zredukować koszty dużych podpisów PQC w PKI opartym o CT poprzez integrację konstrukcji logu z wystawianiem certyfikatu i użycie technik typu podpisywanie hashy drzewa Merkle.
Praktyczne konsekwencje / ryzyko
Co to zmienia dla organizacji i operatorów usług?
- Kompatybilność: jeżeli MTC wejdzie do praktyki, pojawi się okres współistnienia „klasycznego” X.509 i nowych konstrukcji (nowe typy danych w handshake, nowe ścieżki weryfikacji).
- Wpływ na wydajność: celem jest zmniejszenie narzutu, ale przejście wymaga zmian w narzędziach, bibliotekach i procesach CA/PKI.
- Zależność od ekosystemu CA i CT: ponieważ CT jest filarem WebPKI, implementacje muszą utrzymać adekwatności transparentności (monitorowalność, odporność na nadużycia). PLANTS podkreśla, iż projekt ma uwzględniać bezpieczeństwo, prywatność i adekwatności wdrożeniowe.
- Ryzyko „kto pierwszy, ten zabetonuje”: w kryptografii przejściowej duże ryzyko to szybkie przyjęcie rozwiązań, które później trudno zmienić (ossification). Stąd nacisk na proces w IETF i interoperacyjność.
Rekomendacje operacyjne / co zrobić teraz
- Rozdziel w planach migracyjnych dwa strumienie:
- PQC dla key exchange (ochrona przed harvest-now/decrypt-later),
- PQC dla certyfikatów/podpisów (tożsamość, WebPKI, CT).
- Sprawdź koszt „cert bytes” w Twoim ruchu:
- zmierz rozmiary łańcuchów certyfikatów, częstość pełnych handshake’ów (szczególnie QUIC), wpływ na TTFB i p95/p99.
- To pomoże ocenić, jak bardzo PQ podpisy „zabolałyby” w klasycznym modelu (i dlaczego rozwiązania typu MTC są atrakcyjne).
- Monitoruj kierunek PLANTS i działania Chrome Root Store:
- PLANTS ma konkretne kamienie milowe w 2026 r. (architektura i potem dokument standardu).
- Dla zespołów bezpieczeństwa oznacza to: śledzenie zmian w wymaganiach WebPKI oraz planów głównych przeglądarek.
- W środowiskach testowych przygotuj się na „nowe konstrukcje certyfikatów”:
- aktualizuj biblioteki TLS, komponenty reverse-proxy, terminatory TLS, narzędzia inspekcji.
- Zadbaj, aby obserwowalność (monitoring handshake, telemetry) potrafiła odróżnić klasyczne ścieżki od eksperymentalnych.
- Nie odkładaj PQ key exchange:
- ryzyko harvest-now/decrypt-later dotyczy danych przechwytywanych już dziś; wdrożenia hybrydowych mechanizmów w TLS 1.3 są standaryzowane jako konstrukcja „hybrid key exchange”.
Różnice / porównania z innymi przypadkami
PQC w TLS: dlaczego „key exchange” jest łatwiejszy niż „certyfikaty”
- Key exchange (np. hybrydowy) można wprowadzać po stronie klient/serwer jako aktualizację stosu TLS, z relatywnie małą ingerencją w globalne PKI. IETF opisuje konstrukcję hybrydowej wymiany kluczy w TLS 1.3 jako użycie wielu algorytmów naraz, by zachować bezpieczeństwo, jeżeli choć jeden komponent pozostaje odporny.
- Certyfikaty/podpisy dotykają WebPKI, CA, CT, audytu, ekosystemu logów oraz „bagażu kompatybilności” X.509. Stąd podejście Chrome: zamiast natychmiast pchać PQ podpisy do klasycznego łańcucha, szuka się architektury, która ograniczy narzut (MTC + praca PLANTS).
Podsumowanie / najważniejsze wnioski
- Google sygnalizuje, iż „quantum-safe certyfikaty” to problem architektury PKI i CT, nie tylko podmiany algorytmu podpisu w X.509.
- Merkle Tree Certificates (MTC) mają potencjał znacząco ograniczyć koszty transmisji w handshake, bo „certyfikat” staje się lekkim dowodem Merkle, a podpis CA obejmuje zbiorczo wiele wpisów.
- IETF (PLANTS) idzie w tym samym kierunku: standaryzacja mechanizmów, które zachowają transparentność i bezpieczeństwo WebPKI przy dużych podpisach post-quantum.
- Dla organizacji najlepsza strategia „tu i teraz” to: wdrażać PQ key exchange tam, gdzie można, mierzyć koszty cert chainów, i równolegle obserwować oraz testować zmiany w obszarze certyfikatów.
Źródła / bibliografia
- Google Online Security Blog — „Cultivating a robust and efficient quantum-safe HTTPS” (luty 2026). (Google Online Security Blog)
- SecurityWeek — „Google Working Towards Quantum-Safe Chrome HTTPS Certificates” (marzec 2026). (SecurityWeek)
- IETF Datatracker — PLANTS (PKI, Logs, And Tree Signatures), charter i cele grupy roboczej. (datatracker.ietf.org)
- IETF Internet-Draft — „Hybrid key exchange in TLS 1.3” (draft-ietf-tls-hybrid-design). (datatracker.ietf.org)
- Cloudflare Blog — „State of the post-quantum Internet in 2025” (październik 2025). (The Cloudflare Blog)