Hackeři získali certifikáty pro Google. Vaše AI by jim také mohla věřit

Web může mít důvěryhodný certifikát, šifrované spojení a přesto patřit útočníkovi. Přesně takový problém popsal Google 6. října 2026. Hackeři získali neoprávněné certifikáty pro některé jeho domény i další služby. Šifrování přitom nemuseli prolomit. Stačilo zmanipulovat infrastrukturu, podle které internet poznává, komu vlastně věří.

Pro provozovatele webů, firemních AI asistentů nebo chytré energetiky je to nepříjemná připomínka. Sebechytřejší model může poslušně komunikovat s podvodným serverem. A ještě vám hezky česky vysvětlí, že všechno proběhlo v pořádku.

Hackeři získali certifikáty pro Google. Vaše AI by jim také mohla věřit

Útočníci zasáhli správu tří národních doménových koncovek: .gh, .sl a .as. Patří Ghaně, Sieře Leone a Americké Samoi. Změnili autoritativní DNS záznamy a získali certifikáty pro domény, které jim nepatřily. Google výslovně uvádí, že jeho vlastní systémy napadené nebyly. Zároveň nemá důvod předpokládat pochybení vydávajících certifikačních autorit.

Chrome identifikované certifikáty zablokoval prostřednictvím mechanismu CRLSets. Google také zajistil odvolání neoprávněných certifikátů pro své služby. Nezveřejnil však úplný seznam dotčených domén ani konečný počet certifikátů. Z oznámení proto nelze udělat závěr, že útočníci ovládli hlavní adresu google.com. Podrobnosti zveřejnil bezpečnostní tým Googlu.

Výraz „falešný certifikát“ trochu mate. Nemuselo jít o nekvalitní padělek s neplatným podpisem. Problém spočíval v neoprávněném vydání skutečného certifikátu. Útočník přesvědčil ověřovací mechanismus, že doménu kontroluje.

Pro AI aplikace z toho plyne konkrétní riziko. Agent stahující dokumenty, účetní asistent nebo systém načítající ceny elektřiny spoléhá na síťové knihovny. Pokud přijmou podvrženou identitu serveru, model sám nemá spolehlivý způsob, jak podvod poznat. Plynulá odpověď ani správně vypočítaná tabulka důvěryhodnost vstupu nepotvrzují. Bezpečnost spojení musí vyřešit aplikace pod modelem.

Jak obejít důvěru, aniž by praskla jediná šifra

DNS funguje jako adresář. Z názvu služby pomůže zjistit, kam se připojit. Certifikační autorita zase před vydáním běžného doménového certifikátu ověřuje kontrolu nad doménou. Žadatel například zveřejní určený záznam v DNS nebo odpověď na určené webové adrese.

Jestliže útočník ovládne směrování těchto kontrol, může požadovaný důkaz předložit sám. Autorita ověří správnou odpověď, ale od nesprávné osoby. Šifrovací algoritmus dál funguje. Zklame vazba mezi internetovým jménem a skutečným provozovatelem.

Samotné držení certifikátu ovšem automaticky neodhalí hesla všech uživatelů. Útočník potřebuje také dostat jejich komunikaci na svůj server nebo získat vhodnou pozici v síti. Certifikát rovněž není univerzální klíč k dříve zaznamenaným spojením. Rozlišovat tyto podmínky je podstatné: jinak z reálného incidentu vyrobíme internetovou apokalypsu na objednávku.

Pomáhá veřejná evidence Certificate Transparency, zkráceně CT. Umožňuje dohledat vydané certifikáty a odhalit překvapení, o kterých správce domény neví. Evidence ale sama o sobě nevypíná podvodný server. Je to detektor, nikoliv zásahová jednotka. Princip vysvětluje projekt Certificate Transparency.

Provozní poučení je jednoduché. Nestačí hlídat datum konce vlastního certifikátu. Potřebujete vědět také to, zda někdo nevystavil další certifikát pro stejná jména. Včetně zapomenuté regionální domény, kterou marketing přestal používat před třemi lety.

Chcete ušetřit na energiích?

Zjistěte, kolik můžete ušetřit sdílením elektřiny z FVE nebo optimalizací bateriového úložiště.

Spočítat úsporu →

První kontrola domény stojí několik minut

Začněte inventurou domén, jejich správců a používaných certifikačních autorit. Přidejte vývojová prostředí, rozhraní API a regionální weby. U každé položky určete člověka, který pozná oprávněnou změnu. Bez tohoto seznamu budete těžko rozlišovat útok od pátečního zásahu kolegy.

Na Linuxu s dostupnými nástroji `dig` a OpenSSL můžete začít těmito příkazy. Ukázkovou doménu nahraďte vlastní:

```bash dig example.com NS +short dig example.com CAA +short

openssl s_client \ -connect example.com:443 \ -servername example.com \ -verify_hostname example.com \ -verify_return_error

První dotaz ukáže jmenné servery. Druhý pravidla CAA, která omezují vydávání certifikátů. OpenSSL naváže spojení a požaduje ověření jména i certifikačního řetězce. Podrobnosti přepínačů obsahuje oficiální dokumentace OpenSSL.

Výsledek je pouze okamžitý pohled z jednoho místa. Neprokazuje, že jinde neběží jiný server nebo že nebyl vydán další certifikát. Proto jej doplňte sledováním CT.

Základní záznam CAA může vypadat následovně:

```dns example.com. 3600 IN CAA 0 issue "letsencrypt.org" ```

Použijte jej pouze tehdy, když vašim službám skutečně stačí Let’s Encrypt. Jinak můžete rozbít automatickou obnovu certifikátů hostingu. CAA lze doplnit omezením na konkrétní účet ACME. Během úplného ovládnutí DNS může útočník změnit také CAA; po obnovení kontroly ale přísnější pravidla pomáhají zabránit dalšímu vydávání. Možnosti popisuje Let’s Encrypt.

Lokální AI jako pomocník správce: praktický začátek s Ollamou

Umělá inteligence má v tomto procesu smysl při vysvětlování a třídění událostí. Dostane strukturovaný záznam: doménu, vydavatele, platnost, změnu DNS a informaci o plánované údržbě. Vrátí srozumitelný komentář pro správce. Kryptografické ověření musí dál provádět standardní knihovna.

Pro malý experiment můžete použít otevřený nástroj Ollama a model Qwen3 se čtyřmi miliardami parametrů. Varianta `qwen3:4b` má v katalogu velikost přibližně 2,5 GB a používá kvantizaci Q4_K_M. To je velikost modelového souboru, nikoliv celková spotřeba paměti. Parametry uvádí katalog Ollamy.

Po instalaci Ollamy a spuštění její služby stáhnete model:

```bash ollama pull qwen3:4b ```

Potom odešlete jednoduchý místní požadavek:

```bash curl http://localhost:11434/api/generate \ -H 'Content-Type: application/json' \ -d '{ "model": "qwen3:4b", "stream": false, "prompt": "Odpověz česky. Vysvětli správci tuto událost: pro firemní doménu byl vydán certifikát neznámou autoritou. Plánovaná změna není evidována. Uveď, co ověřit. Netvrď, že je útok potvrzen." }' ```

Rozhraní odpovídá dokumentaci Ollamy. Jde o demonstraci, nikoliv hotový bezpečnostní dohled.

Pro první pokus použijte existující počítač s 16 GB RAM a krátkými vstupy. Výkon změřte na vlastních záznamech. Nedávejte modelu přístupová hesla ani pravomoc měnit DNS. Text z logu může obsahovat útočníkovy instrukce; aplikace jej musí považovat za nedůvěryhodná data.

d1 a Nemotron: dvě schopnosti, které není radno zaměňovat

Zprávy o modelech d1 a Nemotronu ukazují dvě odlišné cesty. Liquid AI u rodiny d1 pracuje se strukturovaným rozhodováním. Model dostane situaci a otázky, potom vrací pravděpodobnosti nabízených odpovědí. Nemusí nejprve napsat odstavec, ze kterého další program pracně loví „ano“.

Oficiální představení d1 popisuje práci s textem i obrázky a vyhodnocení jedním průchodem modelem. To je zajímavý princip pro třídění upozornění nebo místní zpracování obrazových vstupů. Nejde však o důkaz, že model pozná neoprávněný TLS certifikát. Takový úkol vyžaduje vlastní měření. Architekturu použití vysvětluje Liquid AI.

NVIDIA mezitím zveřejnila výsledky specializací Nemotronu pro matematickou a informatickou olympiádu. U IOI 2026 uvádí 535,4 bodu ze 600, nad zlatou hranicí 361,12 bodu. Popisuje kombinaci dolaďování, posilovaného učení a zpětné vazby při řešení. Jde o výsledky uváděné autory systému. Zprávu publikovala NVIDIA na Hugging Face.

Olympiádní výkon ale není bezpečnostní certifikace. Model může výborně navrhnout algoritmus a současně chybně posoudit provozní událost. Správce potřebuje měřit přehlédnuté útoky, falešné poplachy a dobu zpracování. Medailová tabulka mu tyto údaje nedodá. Pro dohled nad několika doménami může být nakonec nejlepší obyčejné pravidlo a AI pouze jeho překladatel do lidské řeči.

Kolik to stojí a kdy má smysl LoRA

Pokud už vhodný počítač máte, první lokální experiment nevyžaduje nákup grafické karty ani předplatné modelového rozhraní. Nulový účet za volání modelu však neznamená nulové náklady. Platíte elektřinu, správu a čas člověka, který kontroluje výsledky.

Vezměme modelový výpočet. Zařízení o průměrném příkonu 20 W spotřebuje za třicet dní nepřetržitého provozu 14,4 kWh. Při předpokládané ceně 6 Kč/kWh jde o 86,40 Kč měsíčně. Počítač s průměrem 100 W vyjde za stejných podmínek na 432 Kč. Jsou to výpočtové předpoklady, nikoliv nabídka dodavatele nebo naměřená spotřeba konkrétní sestavy.

Dražší může být lidská obsluha. Deset zbytečných upozornění denně, každé na dvě minuty, znamená přibližně deset hodin práce měsíčně. Právě tady má kvalitní třídění větší hodnotu než honba za dalšími tokeny za sekundu.

LoRA umožňuje přizpůsobovat model trénováním menších přídavných matic místo úpravy všech vah. Otevřenou implementaci nabízí knihovna PEFT na Hugging Face. Ani LoRA ovšem nevyrobí kvalitní trénovací data.

Nejdřív si vytvořte například 200 ručně označených událostí. Oddělte běžnou obnovu, schválenou změnu dodavatele a skutečně podezřelé vydání. Část příkladů si nechte výhradně na závěrečný test. Pokud jednoduchá pravidla vyjdou stejně dobře, dolaďování odložte. Rozpočet raději věnujte pokrytí všech domén a spolehlivému doručování upozornění.

Když podvržená data potkají baterii nebo firemní elektroměr

V energetice se síťová důvěra dotýká skutečných zařízení. Monitoring sbírá měření, aplikace vyhodnocuje spotřebu a řídicí systém může posílat povely. TLS chrání přenos mezi konkrétními body. Samo nezaručí správnost naměřené hodnoty ani oprávněnost navrženého zásahu.

Představte si modelovou situaci: AI dostane podvrženou cenu elektřiny a doporučí vybít baterii. Výpočet může být matematicky správný, ekonomický výsledek špatný. Proto mají fyzické limity, časová platnost vstupů a oprávnění k ovládání fungovat nezávisle na jazykovém modelu.

Při výběru IoT monitoringu se ptejte, jak systém ověřuje identitu zařízení, řeší výpadek spojení a zaznamenává zásahy. U obchodování flexibility chtějte znát hranice vzdáleného řízení. U řešení pro firmy určete vlastníka účtů, dat a provozních rozhodnutí. Tyto otázky patří do zadání bez ohledu na značku dodavatele.

Energetické služby představuje SmartEnergyShare.com. Související témata virtuálních elektráren nabízí také [SmartEnergyShare.cz](https://smartenergyshare.cz). Odkaz na službu ovšem nenahrazuje technické prověření konkrétní instalace.

Také OTE ve svém materiálu zdůrazňuje přístupová oprávnění, bezpečnostní monitoring a integritu záznamů. To jsou užitečné základy i pro menší projekt. Materiál OTE o kybernetické bezpečnosti není zprávou o tomto útoku; poskytuje český provozní kontext.

Co udělat ještě tento týden

Vyberte jednu skutečně používanou doménu. Dohledejte její DNS správu, aktuální certifikáty a lidi s přístupem. Zapněte vícefaktorové ověřování administrace, projděte oprávnění a ověřte, komu přijde upozornění na změnu. U registrátora zjistěte dostupné možnosti ochrany změn delegace.

Potom zkuste malý provozní test. Vyvolejte neškodné zkušební upozornění a sledujte, zda dorazí odpovědnému člověku. Nestačí, že se objeví na nástěnce, kterou nikdo neotevírá. Změřte dobu od události k reakci a určete zastupování pro dovolenou.

AI přidejte až k fungujícímu procesu. První týden ať pouze připravuje vysvětlení. Porovnávejte je s hodnocením správce. Zaznamenejte každou vymyšlenou příčinu, přehlédnutý detail a zbytečně sebejisté doporučení. Teprve podle výsledků rozhodněte, zda šetří práci.

Při podezření na skutečné neoprávněné vydání uchovejte důkazy, obnovte kontrolu nad doménou a kontaktujte vydávající autoritu. Prověřte také možné následné zneužití účtů. Pouhá výměna vlastního certifikátu neodvolá ten útočníkův.

Příští nepříjemný incident může způsobit agent, který chybnému vstupu uvěří a okamžitě podle něj jedná. Začněte proto dnes inventurou a dohledem. Automatizace je skvělá ve zrychlování práce. Bohužel umí stejně ochotně zrychlovat chyby.

Zdroje

Google: reakce Chromu na únosy národních domén — Primární oznámení incidentu z 6. října 2026. Rozlišuje kompromitovanou doménovou infrastrukturu od systémů Googlu a popisuje blokování certifikátů i doporučená opatření pro správce domén.

Let’s Encrypt: nastavení pravidel CAA — Technická dokumentace k omezení vydávajících autorit, validačních metod a účtů ACME. Praktický podklad pro konfiguraci; před změnou je nutné zohlednit autority používané hostingem a dalšími službami.

Liquid AI: představení rozhodovacího modelu d1 — Vysvětlení práce s textovými a obrazovými vstupy a strukturovanými odpověďmi. Uváděná měření pocházejí od výrobce a sama nepotvrzují účinnost modelu při odhalování bezpečnostních incidentů.

NVIDIA: specializace Nemotronu pro IOI a IMO — Autorská zpráva o soutěžních výsledcích a použitých metodách přizpůsobení modelů. Slouží jako podklad k rozlišení matematických a programátorských schopností od požadavků na spolehlivý bezpečnostní dohled.

OTE: operátor trhu a kybernetická bezpečnost — Český materiál o ochraně informačních systémů v energetice. Poskytuje kontext k přístupovým právům, monitoringu a auditním záznamům; neslouží jako aktuální právní návod ani doklad napadení OTE.

Obchodujete s batteriovými úložišti nebo hledáte partnera pro flexibilitu a day trading elektřiny? SmartEnergyShare nabízí kompletní řešení pro BESS projekty od 50 do 250 kW — obchodování flexibility, SVR služby a IoT monitoring. Zjistěte víc →

Další články na toto téma najdete na: SmartEnergyShare.info Žebříček AI agentů odhalil nepříjemnou pravdu: větší mode... Vice o these are