Zámek byl platný, web byl falešný: únosy registrů .gh, .sl a .as vysvětleny

Dne 6. října 2026 zveřejnil bezpečnostní tým Chromu v Googlu krátký příspěvek se suchým názvem a alarmujícím obsahem: útočníci ovládli tři registry národních domén, ghanskou .gh, .sl Sierry Leone a .as Americké Samoy, změnili autoritativní DNS záznamy a získali platné certifikáty HTTPS pro domény Googlu a pro “několik předních světových značek”, které nejmenoval. Kdokoli by přistál na jednom z falešných webů, viděl by v prohlížeči zámek, na kterém nebylo nic špatně.

Tento incident stojí za to pochopit pořádně, protože sedí přesně v bodě, kde je mentální model webové bezpečnosti většiny lidí chybný. Zámek neznamená “tohle je pravý web”. Znamená něco mnohem užšího a koncem září se mezera mezi těmi dvěma významy stala funkčním útokem.

Celou tuto stránku nese jedna definice: certifikát s validací domény dokazuje jedinou věc, totiž že v okamžiku vydání žadatel ovládal DNS domény. Když je registr nad DNS ukraden, je zloděj pro každou automatizovanou kontrolu na světě vlastníkem.

Co se stalo s .gh, .sl a .as?

Registr národní domény je organizace, která vede hlavní databázi všeho pod svou dvoupísmennou doménou: .gh provozuje Network Computer Systems z Akkry, .sl telekom Sierratel a .as spravuje AS Domain Registry. Kompromitujte tuto databázi a nemusíte se nabourávat do žádného jednotlivého webu, protože můžete jakékoli jméno pod TLD předelegovat na servery, které ovládáte.

Přesně to se stalo, registr po registru. Certifikáty se objevily ve veřejných lozích pro jména .gh 22. září, .sl 25. září a .as 27. září, což se čte jako parta pracující podle seznamu. Google říká, že útočníci “upravili autoritativní DNS záznamy a získali neautorizované certifikáty HTTPS pokrývající několik domén Googlu i domény patřící jiným organizacím” a že jeho vlastní systémy zůstaly nedotčeny.

Pozoruhodně mnoho zůstává nezveřejněno: jak byly registry prolomeny, kdo to udělal, zda byl některý certifikát použit proti skutečným uživatelům, i úplný seznam obětí. Žádný ze tří operátorů registrů nezveřejnil k okamžiku psaní tohoto textu prohlášení. Píšeme “nezveřejněno” tam, kde to je stav věcí, a totéž by měl dělat každý text, který čtete.

Jak útočníci získali platné certifikáty pro domény Googlu?

Slušným požádáním. The Hacker News, pracující s veřejným záznamem Certificate Transparency, napočítal nejméně 12 certifikátů pokrývajících 7 domén Googlu a YouTube, mezi nimi google.com.gh, google.sl, google.as a varianty: 11 vydala Let’s Encrypt a 1 ZeroSSL, všechny s validací domény. Člen týmu Let’s Encrypt potvrdil vydání i odvolání na fóru projektu.

A teď ta nepříjemná část: certifikační autority dodržely svá pravidla. Sám Google napsal, že “nemá důvod se domnívat, že certifikační autority (CA), které vydaly dotčené certifikáty, udělaly cokoli špatně”. Validace domény žádá žadatele, aby prokázal kontrolu nad DNS domény, typicky zveřejněním záznamu. Útočníci byli DNS. Každou automatizovanou kontrolou, které čelili, prošli poctivě, v tom úzkém smyslu, v jakém stroje poctivosti rozumějí.

Jeden detail ukazuje, jak na této vrstvě vypadá bdělost: v prověřených záznamech logů, sahajících nejméně k 10. září, pocházel každý jiný certifikát pro google.com.gh, google.sl a google.as od Google Trust Services, vlastní CA Googlu. Dvanáct certifikátů od dvou nesouvisejících autorit bylo samo o sobě anomálií, která seděla ve veřejném logu a čekala, až se někdo podívá.

Kdo to odhalil a jak to bylo zastaveno?

Tři mechanismy, seřazené podle rychlosti.

Zaprvé, Certificate Transparency vůbec učinila certifikáty viditelnými. Od 30. dubna 2018 Chrome odmítá jakýkoli certifikát nezveřejněný ve veřejných CT lozích, takže útočník, který chce certifikát fungující v nejpoužívanějším prohlížeči světa, musí světu zároveň odevzdat podepsané přiznání, že certifikát existuje. Veřejné počítadlo ekosystému přesahuje 2,5 miliardy zaznamenaných certifikátů a sama Let’s Encrypt překročila deset milionů certifikátů vydaných za jediný den koncem září 2025; najít v té kupce sena 12 špatných je přesně to, k čemu infrastruktura logů je.

Zadruhé, Chrome certifikáty zablokoval přes CRLSets, svůj nouzový blokační seznam, který se šíří přes aktualizátor komponent prohlížeče a účinkuje bez aktualizace či restartu. Bezpečnostní tým Chromu léta argumentuje, že online kontroly odvolání selžou přesně tehdy, když je potřebujete, protože útočník uprostřed spojení může zablokovat samotnou kontrolu; blokační seznam proto cestuje s prohlížečem. Google pak v datech CT dohledal další oběti, zablokoval i jejich certifikáty a říká, že dotčené organizace kontaktoval tam, kde mohl.

Zatřetí, pomalá cesta, která kryje všechny ostatní: CA odvolaly všech 12 certifikátů, dva certifikáty .gh a jediný certifikát ZeroSSL 26. září, zbylých devět 1. října. Nejkratší okno mezi objevením certifikátu v logu a jeho smrtí bylo asi den a půl; nejdelší téměř týden. Googleova vlastní doložka poctivosti si zaslouží citaci: “nemůžeme zaručit, že naše analýza identifikovala každou dotčenou doménu, a zásahy Chromu spolehlivě nechrání uživatele jiných prohlížečů”.

Zabránily by tomu DNSSEC nebo záznamy CAA?

Tento incident je nejčistší ukázkou za řadu let, co tyto dvě zkratky kupují a co ne.

Nejdřív DNSSEC. Pohled do zveřejněné kořenové zóny: .gh a .sl nejsou podepsané vůbec, což je řadí mezi mnoho ccTLD, které DNSSEC nikdy nenasadily, technologii s 99 procenty adopce mezi registry v Evropě, ale 65 procenty v Africe. A .as podepsaná je, a stejně byla unesena. DNSSEC umožňuje resolveru ověřit, že odpověď odpovídá tomu, co registr zveřejnil. Když je nepřátelský samotný registr, zveřejňuje data útočníka, včetně klíčů. Podpis pod lží je pořád platný podpis.

Záznamy CAA, jimiž vlastník domény deklaruje, které CA pro ni smějí vydávat, mají jemnější tvar. Během únosu jsou k ničemu, protože záznam CAA žije v tomtéž DNS, které útočník ovládá; sám standard CAA připouští, že útočník schopný editovat DNS může záznam odstranit. Po únosu ale znamenají hodně, protože CA smějí podle současných pravidel CA/Browser Fora znovu použít dokončenou validaci až 200 dní, okno, které klesá na 100 dní v březnu 2027 a na 10 dní v roce 2029, takže útočník, který už DNS ztratil, by stále mohl razit čerstvé certifikáty z uložených kontrol. K 7. říjnu neslo všech sedm známých zasažených domén Googlu záznamy CAA jmenující výhradně vlastní CA Googlu. To je zámek, který montujete po téhle konkrétní vloupačce, a je skutečný.

Stalo se to už někdy dřív?

Útoky na registry a infrastrukturu DNS jsou žánr, ne novinka. Datovaný záznam:

Mezi zhruba 1 400 doménami v kořenové zóně je 316 národních TLD, každá vázaná na zemi či území, každá s vlastním rozpočtem, správou a úrovní zabezpečení, a některé provozují soukromí operátoři. Ghanský zákonný doménový úřad strávil roky ve veřejném sporu o to, kdo by měl .gh vůbec provozovat. Model důvěry webu zčásti stojí na tom, že i ta nejhůře financovaná z těchto organizací má dobrý bezpečnostní tým.

Co byste viděli a co vás skutečně chrání?

Kdyby vás během toho okna někdo přesměroval na jeden z falešných webů, neviděli byste nic. Platný certifikát, normální zámek, žádné varování; jak to formuloval Ars Technica, držení takových certifikátů “umožňuje útočníkům kryptograficky se vydávat za zasaženou infrastrukturu”. Zda tam někdo skutečně přesměrován byl, patří k nezveřejněným faktům.

Co uživatele ochránilo, nebylo nic, co by udělal uživatel. Povinná papírová stopa CT certifikáty odhalila, CRLSets je v Chromu zabily bez jakéhokoli zásahu a odvolání pokrylo zbytek. Jedna vrstva navíc stojí za zmínku: nativní aplikace, které si připínají své klíče. V případu Toga z roku 2017 by pinning Chromu podvodný certifikát google.tg odmítl tak jako tak a vlastní aplikace Googlu i řada bankovních aplikací si klíče připínají dodnes. Obrana do hloubky tu není slogan; je to konkrétní sestava a koncem září nesla váhu každá její vrstva.

Chrání před tímhle VPN?

Poctivá stránka o bezpečnosti odpovídá na tuto otázku přesně, takže tady je přesná odpověď: ne pro tuto třídu útoku, ano pro její běžnější příbuzné, a vědět, co je co, je celá hra.

VPN se neúčastní TLS. Váš prohlížeč ověřuje certifikáty proti svému úložišti důvěry stejně na jakékoli síti a tyto certifikáty platné byly. Hůř pro jakýkoli nástroj po proudu od DNS: útočníci otrávili autoritativní záznamy v registru, takže každý poctivý resolver na planetě, včetně resolverů poskytovatele VPN, servíroval odpovědi útočníka. Žádná VPN, ani ta naše, by tohle nezablokovala. Zastavil to výše popsaný řetězec CT, CRLSet a odvolání.

Co VPN brání, je vaše strana spojení. Na nepřátelské místní síti, na podvrženém hotspotu nebo u manipulujícího ISP sedí útočník mezi vaším zařízením a internetem, podstrkává DNS odpovědi nebo přesměrovává provoz. VPN přesouvá vaše překládání DNS i cestu vašeho provozu do šifrovaného tunelu, jak to formuluje průvodce EFF, skrývá váš provoz před “vaším ISP a vlastníkem místní sítě (jako je kavárna nebo hotel)”. To je ten běžný, každodenní útočný povrch, ten, kterému se věnujeme v průvodcích šifrováním VPN a bezpečností veřejné Wi-Fi, a je to přesně ta vrstva, které se útočníci na registry nikdy nemuseli dotknout. Obě ochrany se doplňují, nejsou zaměnitelné, a proto také vedeme samostatnou poctivou stránku o tom, co weby vidí i se zapnutou VPN.

Co by teď měli udělat vlastníci domén?

Rada Googlu organizacím má dva kroky a platí stejně pro firmu se třemi doménami jako pro tu s třemi tisíci. Sledujte logy Certificate Transparency pro každou doménu, kterou držíte, včetně zaparkovaných a regionálních; 12 podvodných certifikátů leželo ve veřejných lozích celé dny, viditelné každému, kdo se díval. A zveřejněte restriktivní záznamy CAA jmenující vaši CA, ideálně s vazbou na účet ACME, aby i vaše vlastní CA vydávala jen na váš účet. Pravidla CA přidávají třetí krok: objeví-li se nevyžádaný certifikát, podejte Certificate Problem Report, který musí CA podle oborových Baseline Requirements prošetřit a do 24 hodin oznámit první zjištění.

Pro všechny ostatní jsou závěry menší, ale skutečné. Udržujte prohlížeč aktuální, protože blokační seznam, který zachránil uživatele Chromu, cestuje s ním. Berte zámek jako to, čím je, výrok o šifrování při přenosu, ne o tom, kdo je na druhém konci. A umísťujte každý nástroj do jeho vlastní vrstvy: systém certifikátů ověřuje weby, VPN chrání cestu, kterou váš provoz putuje, a zářijový incident potřeboval, aby ten první selhal bezpečně, zatímco ten druhý vůbec nebyl ve hře.