Ponad 2/3 ruchu z przeglądarek do Cloudflare używa już ML-KEM, a UE chce migracji krytycznych systemów do 2030. Sprawdziliśmy 12 serwerów, w tym własne.
Kryptografia postkwantowa jest już w Twojej przeglądarce: Chrome, Firefox i Safari domyślnie negocjują wymianę klucza X25519MLKEM768, a ponad dwie trzecie ruchu z przeglądarek do sieci Cloudflare jest szyfrowane odpornie na komputery kwantowe. Czy dotyczy to także Twojej strony, zależy wyłącznie od serwera. Terminy są wyznaczone: Unia oczekuje krajowych strategii i inwentaryzacji kryptografii do końca 2026 r. i migracji systemów krytycznych do 2030 r., NIST wycofuje RSA-2048 i ECC do 2030 r. (zakaz od 2035), a rozporządzenie wykonawcze prezydenta USA z 22 czerwca 2026 r. nakazuje agencjom przejście do końca 2030 r. Sprawdziliśmy 10 września 2026 r. dwanaście serwerów, w tym własne - wyniki niżej, bez upiększania.
Bezpieczeństwo HTTPS, VPN, SSH i podpisów elektronicznych opiera się na tym, że klasyczny komputer nie rozłoży dużej liczby na czynniki ani nie policzy logarytmu dyskretnego. Algorytm Shora na wystarczająco dużym komputerze kwantowym robi to w rozsądnym czasie, więc RSA i krzywe eliptyczne (ECDH, ECDSA) przestaną chronić dane. Szyfrowanie symetryczne (AES) i funkcje skrótu (SHA-2) pozostają bezpieczne przy dłuższych kluczach.
Problem nie zaczyna się w dniu, w którym taki komputer powstanie. Ruch szyfrowany dziś można nagrać i odszyfrować za kilka lat („harvest now, decrypt later"). Dlatego wymianę klucza trzeba zmienić już teraz - chroni ona wszystko, co przesyłasz - a podpisy (certyfikaty) mogą poczekać do czasu, gdy zagrożenie stanie się realne, bo podrobić podpis trzeba na żywo. Ile lat mają Twoje dane? Umowy, dokumentacja medyczna, dane kadrowe i kopie zapasowe zwykle więcej niż dziesięć.
Metoda: klient OpenSSL 3.5.6, komenda openssl s_client z domyślną listą grup, 10 września 2026 r. Wynik „tak" oznacza, że serwer uzgodnił X25519MLKEM768; „nie" - że wybrał klasyczne X25519 albo odrzucił połączenie, gdy zaproponowaliśmy wyłącznie grupę postkwantową.
| Serwer | Rola | X25519MLKEM768 |
|---|---|---|
| cloudflare.com | CDN | tak |
| google.com | wyszukiwarka | tak |
| wordpress.org | strona projektu | tak |
| allegro.pl | e-commerce | tak |
| gov.pl | administracja | nie |
| strony trzech dużych polskich firm hostingowych | hosting | nie |
| mcprodukt.pl | nasza strona (Nginx, OpenSSL 3.4) | nie - obsługę da OpenSSL 3.5, który przyjdzie z aktualizacją systemu serwera |
| serwery WWW klientów (OpenLiteSpeed 1.8.5) | hosting | nie - obsługę da wydanie OpenLiteSpeed, które przeniesie zmianę z LiteSpeed 6.3.2 |
| poczta na serwerze s2 (Dovecot IMAP 993, Exim SMTP 465, AlmaLinux 10 z OpenSSL 3.5) | hosting poczty | tak |
| poczta na serwerze s1 | hosting poczty | nie - starszy system, czeka na aktualizację |
Wniosek jest prosty: giganci i firmy stojące za CDN-ami już przeszły, większość polskich serwerów WWW jeszcze nie, a decyduje wersja biblioteki TLS, nie certyfikat. U nas poczta na serwerze s2 jest już chroniona hybrydowo, a strony WWW dołączą wraz z aktualizacjami oprogramowania serwerów. Publikujemy to, bo lepiej znać stan rzeczy niż wierzyć w hasła „bezpieczny hosting".
openssl s_client -connect twojadomena.pl:443 -groups X25519MLKEM768 (OpenSSL 3.5+). Udane połączenie wypisze „Negotiated TLS1.3 group: X25519MLKEM768", nieudane skończy się błędem „handshake failure".ssh -Q kex na kliencie i serwerze; szukaj „mlkem768x25519-sha256" na obu.| Kto | Termin | Co |
|---|---|---|
| UE (NIS Cooperation Group, mapa z czerwca 2025) | koniec 2026 / 2030 / 2035 | strategie krajowe, inwentaryzacje i pilotaże / migracja systemów wysokiego ryzyka / pozostałe zastosowania |
| NIST IR 8547 | 2030 / 2035 | RSA-2048 i ECC „przestarzałe" / niedozwolone |
| USA, rozporządzenie 14412 (22.06.2026) | 31.12.2030 / 31.12.2031 | wymiana klucza / podpisy w systemach federalnych; nowe zakupy NSS z PQC od 1.01.2027 |
| Wielka Brytania (NCSC) | 2028 / 2031 / 2035 | inwentaryzacja / migracja priorytetowa / pełna migracja |
Nie ma jeszcze takich certyfikatów w przeglądarkach. Wymiana klucza ML-KEM działa z dzisiejszymi certyfikatami RSA i ECDSA; to serwer decyduje, nie certyfikat. Darmowe certyfikaty, o których piszemy w tekście Let's Encrypt - czy darmowy SSL wystarczy, są w tym względzie równe płatnym.
Uzgodnienie połączenia rośnie o około 1-2 kB, co przy HTTP/3 i wznawianiu sesji jest niemierzalne dla użytkownika. Cloudflare obsługuje tak większość ruchu bez zauważalnego kosztu.
IMAP i SMTP używają tego samego TLS, więc decyduje serwer pocztowy i program klienta. Nasza poczta na serwerze s2 negocjuje X25519MLKEM768 z każdym programem, który to obsługuje - na przykład z aplikacjami w iOS i macOS 26, gdzie Apple włączyło hybrydową wymianę klucza domyślnie w systemowym TLS. W Outlooku i Thunderbirdzie zależy to od wersji programu i jego biblioteki TLS; starsze wersje połączą się klasycznie, tak jak dotąd.
Nie musi robić nic poza wybraniem dostawców, którzy aktualizują oprogramowanie. Ta lista pomaga zadać właściwe pytania hostingowi, dostawcy VPN i firmie od podpisów elektronicznych.
Migracja postkwantowa dzieje się po stronie serwerów i bibliotek, a nie w Twoim panelu WordPressa. Sprawdź stronę w zakładce Security, zapytaj dostawców o OpenSSL 3.5 i LiteSpeed 6.3.2, zinwentaryzuj klucze i skróć retencję danych. Stan u nas: poczta na s2 gotowa, strony WWW czekają na aktualizacje oprogramowania serwerów - ten wpis zaktualizujemy, gdy wyniki w tabeli się zmienią. Jeśli potrzebujesz przeglądu bezpieczeństwa strony i poczty, zobacz co obejmuje nasz pakiet bezpieczeństwa.
Wszystkie poradniki z kategorii: Hosting od podstaw