Zielona czy szara, zamknięta czy otwarta, kłódka w pasku adresu to jeden z najbardziej rozpoznawalnych symboli internetu. Na przykładzie incydentu z certyfikatami eMudhra wyjaśniamy, co ten symbol naprawdę oznacza, kto za nim stoi i dlaczego przeglądarka nie zawsze jest jedynym ogniwem łańcucha zaufania.
Mały symbol, duże zaufanie
Większość użytkowników internetu uczono jednej zasady: jeśli obok adresu strony widać kłódkę, można bezpiecznie wpisać hasło, numer karty czy dane osobowe. Zasada jest uproszczona, ale w praktyce działa zaskakująco dobrze, bo za tym niewielkim symbolem kryje się rozbudowany system kryptograficzny, który każdego dnia chroni miliardy połączeń. Rzadko jednak zadajemy sobie pytanie, na czym to zaufanie się opiera.
Kłódka nie mówi, że strona jest uczciwa. Mówi tylko, że połączenie z nią jest szyfrowane i że serwer przedstawił certyfikat, który przeglądarka uznała za wiarygodny. Cały ciężar leży w słowie „uznała“. Przeglądarka nie sprawdza wiarygodności samodzielnie, lecz opiera się na wąskim gronie organizacji, którym z góry zaufano. To właśnie ich bezpieczeństwo decyduje o tym, czy kłódka cokolwiek znaczy.
Jak działa łańcuch zaufania
Kiedy wpisujesz adres banku, serwer odsyła przeglądarce certyfikat, czyli cyfrowy dokument łączący nazwę domeny z kluczem kryptograficznym. Taki certyfikat nie jest wystawiany przez samego właściciela strony. Podpisuje go urząd certyfikacji, który potwierdza, że klucz rzeczywiście należy do właściwej domeny. Urząd certyfikacji robi to zwykle nie bezpośrednio swoim głównym kluczem, lecz za pośrednictwem certyfikatów pośrednich, tworząc łańcuch: certyfikat strony jest podpisany przez pośredni, ten przez kolejny, a na końcu stoi certyfikat główny, który przeglądarka lub system operacyjny ma zapisany na stałe w swoim magazynie zaufanych certyfikatów.
Cała konstrukcja opiera się na jednym założeniu: tajne klucze, którymi podpisuje się kolejne certyfikaty, znają wyłącznie ich właściciele. Kto zdobędzie taki klucz, może wystawić certyfikat dla dowolnej domeny, a oprogramowanie ufające danemu urzędowi uzna go za prawdziwy. Bezpieczeństwo kilku miliardów połączeń zależy więc od tego, czy kilkaset kluczy pozostaje poufnych i czy zostały wygenerowane poprawnie.
Klucz równy czterem
Właśnie to założenie zostało podważone w październiku 2026 roku. Jak opisał Ars Technica, tajnym kluczem jednego z certyfikatów indyjskiej firmy eMudhra okazała się liczba 4. Nie długi ciąg cyfr zaczynający się od czwórki, lecz po prostu cztery. Siedem pozostałych kluczy z tej samej grupy było niewiele większych. Wszystkie osiem miało od 3 do 8 bitów, podczas gdy standardowy klucz tego typu to losowa liczba o długości około 384 bitów, co daje mniej więcej 10 do potęgi 115 możliwych wartości. Różnica między tymi liczbami jest tak ogromna, że porównanie jej do różnicy między kłódką na rower a drzwiami bankowego skarbca byłoby wyrazem litości dla kłódki.
Badacz bezpieczeństwa Scott Helme odzyskał wszystkie osiem kluczy z publicznie dostępnych certyfikatów na swoim laptopie, a według jego relacji zajęło to mniej niż sekundę. Dodał także, że to samo zrobił Claude firmy Anthropic po otrzymaniu jednego polecenia. Kto zdobył taki klucz, mógł wystawić certyfikat dla dowolnej strony, od banku po pocztę elektroniczną.
Nie włamanie, lecz pomyłka
Warto podkreślić, że nie było tu mowy o kradzieży. Z wyjaśnień, które eMudhra przekazała Mozilli, wynika, że winny był błąd w skrypcie używanym przy generowaniu kluczy. Skrypt tworzył drugi, słaby zestaw, a pracownicy omyłkowo wybrali właśnie te klucze, ponieważ ich etykiety wyglądały podobnie. Firma, która deklaruje wydanie ponad 60 milionów certyfikatów cyfrowych, poinformowała Mozillę, że większość wadliwych certyfikatów pośrednich nigdy nie trafiła do użytku i że nie znalazła dowodów, by posłużyły do podpisania certyfikatów dla użytkowników końcowych. Wszystkie osiem unieważniła i wstrzymała wydawanie certyfikatów w ramach wadliwego certyfikatu głównego.
To ważna lekcja, bo pokazuje, że największe ryzyko w systemach kryptograficznych rzadko leży w samej matematyce. Znacznie częściej leży w procesach, skryptach i ludzkich pomyłkach, które matematykę omijają.
Dlaczego przeglądarki były bezpieczniejsze niż reszta
Z punktu widzenia zwykłego użytkownika przeglądarki sytuacja wyglądała znacznie lepiej, niż mogłoby się wydawać. Chrome, Firefox i Safari mają dwa mechanizmy, które ograniczyły skutki błędu. Pierwszy to listy unieważnionych certyfikatów, które przeglądarki po cichu przesyłają użytkownikom w ramach regularnych aktualizacji. Drugi to Certificate Transparency, czyli system publicznych dzienników, w których musi się pojawić każdy certyfikat, by przeglądarka go zaakceptowała. Dzięki temu fałszywy certyfikat wystawiony w ukryciu zostałby odrzucony, nawet gdyby jego podpis był poprawny. Zgodnie z ustaleniami opisanymi w artykule żaden certyfikat strony internetowej powiązany z wadliwymi kluczami nigdy się w tych dziennikach nie znalazł, więc aktualne przeglądarki nie były domyślnie narażone.
Kłopot poza przeglądarką
Problem zaczyna się tam, gdzie przeglądarki nie ma. Narzędzia wiersza poleceń, takie jak curl, języki programowania, na przykład Python, Node i Go, klienci VPN, kontenery Docker oraz urządzenia inteligentnego domu mają własne listy zaufanych urzędów certyfikacji. Rzadko sprawdzają unieważnienia i ignorują dzienniki przejrzystości. Helme stworzył fałszywy certyfikat dla interfejsu płatności Stripe i przekonał się, że curl, Python i Node akceptowały go na każdym testowanym komputerze z Linuksem i macOS.
Filippo Valsorda, opiekun kodu kryptograficznego języka Go, ocenił w rozmowie z Ars Technica, że będzie to gigantyczna akcja porządkowa, większa niż po luce Heartbleed w OpenSSL, której usuwanie trwało latami. Spodziewa się bardzo długiego ogona urządzeń IoT, kontenerów Docker, zapomnianych komputerów z Linuksem i nieaktualizowanych narzędzi, które zawierają własne kopie zaufanych certyfikatów głównych.
Kto mógł z tego skorzystać
Odzyskanie kluczy to jedno, a wykorzystanie ich w praktyce to drugie. Atak wymaga pozycji, w której napastnik może przechwytywać ruch sieciowy między użytkownikiem a internetem. Może to być operator publicznego hotspotu, osoba kontrolująca przejętą sieć biurową, właściciel zhakowanego routera, a w skrajnym przypadku państwo, które kontroluje infrastrukturę sieciową na swoim terytorium. Nie jest to więc zagrożenie, które dotyka każdego i wszędzie, ale też trudno nazwać je teoretycznym.
Nie wszystko jest zagrożone. Signal, WhatsApp i WireGuard nie opierają szyfrowania na tych certyfikatach, więc ten incydent ich nie dotyczy. To dobry przykład tego, że architektura zaufania ma znaczenie: systemy, które nie polegają na zewnętrznych urzędach certyfikacji, nie dziedziczą ich słabości.
Siedemnaście miesięcy ciszy
Najbardziej niepokojące jest to, jak długo luka mogła istnieć. Klucze można było odzyskać od chwili utworzenia certyfikatów w kwietniu 2025 roku, czyli przez około siedemnaście miesięcy. W maju 2025 roku każdy z certyfikatów został dodatkowo podpisany krzyżowo przez główny certyfikat AAA Certificate Services firmy Sectigo, co zwiększyło liczbę systemów, które mu ufały. Nie da się dziś ustalić, czy ktokolwiek wykorzystał te klucze przeciwko oprogramowaniu pomijającemu kontrolę w dziennikach przejrzystości, i warto uczciwie powiedzieć, że brak dowodów nie jest dowodem braku.
Jak szybko zareagował świat
Sama reakcja branży była natomiast szybka. Badacz zgłosił problem producentom przeglądarek 17 października. Tego samego dnia Mozilla zablokowała certyfikaty w Firefoksie w ciągu trzech godzin, a 20 października udostępniła Firefox 158.0.1, nowe wydania ESR oraz NSS 3.131.1, które usuwa główny certyfikat eMudhra. Apple dodało zabezpieczenia 19 października, a Microsoft 20 października. Poprawki pojawiły się także w ekosystemie narzędzi programistycznych, między innymi w Go, pip, uv i certifi, a Cloudflare zaktualizował swoje aplikacje WARP i 1.1.1.1. Chrome potwierdził, że usunie główny certyfikat eMudhra ze swojego magazynu zaufanych certyfikatów.
Nie wszędzie było jednak tak dobrze. Ars Technica zauważył, że w chwili publikacji Edge na Windowsie 10 nadal łączył się z serwerami testowymi, a wbudowany w macOS curl nadal ufał tym kluczom, dopóki plik z certyfikatami nie zostanie ręcznie zmodyfikowany. Dystrybucje Linuksa wciąż udostępniały nowe pakiety z certyfikatami.
Podsumowanie
Kłódka w przeglądarce to wygodny skrót myślowy, za którym stoi system oparty na zaufaniu do niewielkiej liczby urzędów certyfikacji. Incydent z certyfikatami eMudhra, w których tajne klucze miały zaledwie od 3 do 8 bitów, a jeden z nich był po prostu liczbą 4, pokazał, że ten system może zawieść przez zwykły błąd w skrypcie, a nie przez wyrafinowany atak. Przeglądarki dzięki listom unieważnień i Certificate Transparency ochroniły swoich użytkowników, natomiast narzędzia wiersza poleceń, języki programowania, kontenery i urządzenia IoT pozostały podatne dłużej. Dla użytkownika najważniejsze wnioski są praktyczne: aktualizuj oprogramowanie, uważaj w sieciach publicznych i nie traktuj kłódki jako gwarancji uczciwości strony.
Źródła: Ars Technica, BleepingComputer, serwis incydentu prowadzony przez Dennisa Jacksona z Mozilli, Martin Cid Magazine.
