Certyfikaty Merkle: jak HTTPS przygotowuje się na komputery kwantowe

Za każdym razem, gdy otwierasz stronę przez HTTPS, przeglądarka sprawdza łańcuch certyfikatów podpisanych kryptografią, którą w przyszłości mogą złamać komputery kwantowe. Algorytmy odporne na takie ataki już istnieją, ale są duże i ciężkie. Google rozwija więc w organizacji IETF zupełnie nowy model certyfikatów: Merkle Tree Certificates. Według ekspertów to nie kosmetyczna zmiana, tylko przebudowa tego, jak internet buduje zaufanie.

Jak dziś działa zaufanie w HTTPS

Gdy łączysz się ze stroną, serwer wysyła przeglądarce swój certyfikat oraz certyfikat pośredni urzędu certyfikacji (CA), który go podpisał. Przeglądarka sprawdza podpisy w tym łańcuchu aż do urzędu, któremu ufa z góry. Do tego dochodzą podpisy z rejestrów Certificate Transparency, czyli publicznych dzienników, w których każdy certyfikat musi zostać zapisany, żeby nikt nie wystawił po cichu fałszywego certyfikatu dla cudzej domeny.

W jednym połączeniu przesyła się więc kilka kluczy publicznych i kilka podpisów. Przy dzisiejszych algorytmach opartych na krzywych eliptycznych (ECDSA) to niewiele danych: podpis ma około 64 bajtów.

Problem: algorytmy postkwantowe są duże

W sierpniu 2024 roku amerykański instytut NIST opublikował pierwsze standardy kryptografii postkwantowej: ML-KEM do uzgadniania kluczy oraz ML-DSA i SLH-DSA do podpisów cyfrowych. Te algorytmy mają być odporne na ataki komputerów kwantowych, ale płacą za to rozmiarem.

Pomnóż to przez liczbę podpisów i kluczy w jednym połączeniu, a dostaniesz nawet kilkanaście dodatkowych kilobajtów na samo nawiązanie połączenia. Ganesh Mallaya z firmy AppViewX, autor analizy opublikowanej w TechNewsWorld, wylicza skutki: większe certyfikaty to dłuższe nawiązywanie połączenia TLS, większe obciążenie łączy na brzegu sieci i wyraźniejsze opóźnienia tam, gdzie połączeń jest bardzo dużo. Odczują to load balancery, sieci CDN i urządzenia mobilne. Osobno każdy z tych problemów wydaje się do opanowania. W skali całego internetu już nie.

Dlatego, jak przekonuje Mallaya, kryptografii postkwantowej nie da się wdrożyć przez prostą podmianę algorytmów w obecnym modelu certyfikatów. Potrzebna jest zmiana architektury.

Uzgadnianie kluczy już jest postkwantowe

Warto wiedzieć, że połowa problemu jest już rozwiązana. Najpopularniejsze przeglądarki i duzi dostawcy, tacy jak Cloudflare czy Google, od 2024 roku używają hybrydowego uzgadniania kluczy łączącego klasyczny algorytm z ML-KEM. Chroni to przed scenariuszem „zbierz teraz, odszyfruj później”, w którym ktoś nagrywa dziś zaszyfrowany ruch, żeby za kilka lat odczytać go komputerem kwantowym. Klucz ML-KEM jest stosunkowo niewielki, więc dało się go wdrożyć szybko. Z podpisami w certyfikatach jest dużo trudniej.

Czym są Merkle Tree Certificates

Drzewo Merkle'a to struktura danych, w której wiele elementów łączy się parami za pomocą funkcji skrótu, aż do jednego „korzenia”. Wystarczy podpisać sam korzeń, żeby potwierdzić autentyczność wszystkich elementów drzewa. Żeby udowodnić, że konkretny element do niego należy, wystarczy krótki dowód złożony z kilku skrótów. Na tej samej zasadzie działają rejestry Certificate Transparency i blockchain.

Merkle Tree Certificates (MTC) przenoszą ten pomysł do HTTPS. Zamiast przesyłać przy każdym połączeniu pełen łańcuch certyfikatów z kilkoma dużymi podpisami, serwer przesyła zwięzły dowód, że jego certyfikat znajduje się w podpisanym drzewie. Przeglądarka, która zna podpisany korzeń, weryfikuje tylko ten dowód. Duże postkwantowe podpisy nie muszą więc podróżować przy każdym połączeniu.

Mallaya podkreśla, że to więcej niż optymalizacja. Weryfikacja przestaje być liniowym sprawdzaniem łańcucha i staje się sprawdzaniem przynależności do drzewa. Taki model lepiej się skaluje i naturalnie łączy się z Certificate Transparency, gdzie jawność i dowód obecności w rejestrze są już podstawą zaufania. Prace toczą się w grupie roboczej PLANTS w IETF, organizacji, która tworzy standardy internetu. Fakt, że przeglądarki i dostawcy infrastruktury wspólnie przebudowują dystrybucję certyfikatów, oznacza, że redefiniowane są fundamenty sieciowej infrastruktury klucza publicznego (PKI).

Okres przejściowy: certyfikaty hybrydowe

Pełne wsparcie dla nowych algorytmów i nowego modelu certyfikatów zajmie lata. W międzyczasie organizacje będą korzystać z certyfikatów hybrydowych lub złożonych, łączących podpis klasyczny z postkwantowym. Pozwalają zacząć wzmacnianie systemów bez utraty zgodności ze starszymi klientami, ale mają swoją cenę: podwójne ścieżki weryfikacji, bardziej złożony cykl życia certyfikatów, więcej testów zgodności i większe ryzyko błędów konfiguracji. Mallaya ostrzega, że bez solidnych podstaw operacyjnych strategia hybrydowa może przynieść niestabilność zamiast odporności.

Certyfikaty i tak będą żyć coraz krócej

Równolegle zmienia się coś, co dotknie każdego administratora strony. Branżowe forum CA/Browser Forum, w którym przeglądarki i urzędy certyfikacji ustalają zasady, przyjęło w 2025 roku harmonogram skracania maksymalnej ważności certyfikatów TLS:

• do 200 dni od 15 marca 2026 roku,
• do 100 dni od 15 marca 2027 roku,
• do 47 dni od 15 marca 2029 roku.

Ręczne odnawianie certyfikatu raz w roku przestaje więc wchodzić w grę. Mallaya wymienia to jako jeden z elementów nowego modelu operacyjnego: zaufanie trzeba dostarczać sprawnie, weryfikować na bieżąco i dostosowywać do zmieniających się standardów.

Kryptozwinność, czyli przygotowanie na zmianę

Kluczowe pojęcie w tej dyskusji to kryptozwinność (crypto-agility). Zwykle opisuje się ją jako możliwość wymiany algorytmu bez przerywania działania systemów, ale według Mallayi chodzi o więcej: o zdolność do zmiany algorytmów, formatów certyfikatów, sposobów weryfikacji, a nawet mechanizmów ich dystrybucji. Systemy mocno związane z dzisiejszymi formatami certyfikatów będą miały problem z adaptacją, a dodawanie elastyczności później jest powolne i ryzykowne.

Nie wystarczy też sama inwentaryzacja certyfikatów, kluczy i algorytmów. Trzeba wiedzieć, jak zaufanie przepływa między systemami: które aplikacje zależą od których certyfikatów, gdzie wrażliwość na wydajność może ujawnić problemy z kryptografią postkwantową i jak zmiana certyfikatu rozchodzi się po środowisku.

Co powinien zrobić właściciel strony już teraz

1. Zautomatyzuj odnawianie certyfikatów przez protokół ACME (np. Let's Encrypt z certbotem lub wbudowane mechanizmy hostingu). Przy coraz krótszej ważności to warunek konieczny.
2. Aktualizuj serwer i biblioteki TLS (OpenSSL, nginx, Apache). Obsługa algorytmów postkwantowych przychodzi wraz z aktualizacjami.
3. Spisz, gdzie masz certyfikaty: domeny, subdomeny, panele, API, urządzenia w sieci firmowej. Zapomniany certyfikat to najczęstsza przyczyna nagłej awarii.
4. Unikaj sztywnego przypinania konkretnych certyfikatów lub kluczy w aplikacjach, jeśli nie masz procesu ich szybkiej wymiany.
5. Pilnuj poprawnej konfiguracji HTTPS, w tym przekierowań i braku mieszanej treści. Sprawdzisz to naszym detektorem mixed content, a rekordy domeny w narzędziu WHOIS i DNS.

O tym, jak zagrożenie kwantowe dotyka kryptowalut, piszemy w artykule o pierwszej transakcji Bitcoina odpornej na komputery kwantowe.

Najczęściej zadawane pytania

Źródło: Ganesh Mallaya (AppViewX), „Google's Merkle Certificate Push Signals a Rethink of Digital Trust”, TechNewsWorld, 17 kwietnia 2026. Dane o standardach: NIST, CA/Browser Forum.