Tim Hudson, prezident společnosti OpenSSL Corporation – série rozhovorů

Tim Hudson je spoluautorem SSLeay a jedním z organizátorů OpenSSL Conference, Praha 13.–15. října 2026. Má více než 30 let zkušeností v oblasti systémové a síťové bezpečnosti a je prezidentem OpenSSL Corporation a hlavním technologickým ředitelem ve Cryptsoft Pty Ltd. Od roku 1995 jeho práce zahrnovala spoluzaložení SSLeay s Ericem Youngem, kryptografické knihovny, která se stala OpenSSL Library, spoluzaložení vývojového centra RSA Security Australia, přispění ke změnám v amerických exportních předpisech pro šifrování, vedení více než 30 validací FIPS 140, spolupředsednictví v technických výborech OASIS KMIP a SAM a přednášky na předních bezpečnostních konferencích, včetně RSA Conference, AusCERT, ICMC, LinuxConf a OpenSSL Conference.

OpenSSL je globální spolupracující open source projekt, který vyvíjí a udržuje OpenSSL Library, jednu z nejrozšířenějších kryptografických knihoven na světě. Používána napříč operačními systémy, cloudovými platformami, podnikovým softwarem i připojenými zařízeními, OpenSSL Library pomáhá denně chránit miliardy zabezpečených online interakcí. Prostřednictvím OpenSSL Foundation a OpenSSL Corporation se projekt zavazuje podporovat důvěryhodnou kryptografii, udržitelný vývoj open source a posilovat bezpečnost internetu.

Spoluzaložil jste SSLeay s Ericem Youngem v roce 1995 poté, co jste si uvědomil potřebu neamerické implementace SSL, a tato práce se nakonec stala základem pro OpenSSL. Jaký problém jste se původně snažil vyřešit a měl jste v té době představu, že se tato technologie může stát tak zásadní součástí zabezpečení internetu?

Problém byl zcela konkrétní a byl komerční, ještě před tím, než se stal čímkoli jiným. Pracoval jsem ve společnosti Mincom v Brisbane a měli jsme zákazníky, kteří potřebovali zabezpečit své komunikace. Nebyla žádná možnost tuto schopnost zakoupit. Americké exportní kontroly šifrování znamenaly, že americké produkty buď nemohly být vůbec dodány, nebo přišly s tak omezenými velikostmi klíčů, že jejich nasazení by bylo nečestné. Nešlo o filozofický nesouhlas s exportní politikou. Šlo o inženýrský problém, kdy komponenta, kterou jsem potřeboval, neexistovala v žádné formě, kterou bych mohl zakoupit, a zákazníci čekali.

Měl jsem však znalost něčeho, na co většina lidí zapomněla. Eric Young před několika lety napsal implementaci DES: dobrý, čistý, volně dostupný kód, vytvořený pro samotný účel a zcela nesouvisející s tímto. Eric nepracoval na SSL. Nebyl si vědom SSL. Když Netscape zveřejnilo specifikaci, přečetl jsem ji, obrátil se na Erica s problémem a představil mu to jako relativně skromný krok od toho, kde už byl.

Toto nebyl celý obrázek. Každá část byla jednoduchá, ale bylo jich značně mnoho. Implementace DES vám poskytuje jeden symetrický šifrovací algoritmus. SSL vyžaduje kryptografii s veřejným klíčem, aritmetiku libovolné přesnosti, ASN.1, zpracování certifikátů X.509 a stavový stroj protokolu, a to vše správně, protože v kryptografii je rozdíl mezi téměř správným a porušeným prakticky neexistuje. Původně jsem rozsah projektu prezentoval optimisticky. Eric brzy pochopil, kolik toho je, a užíval si to, protože rozsah se ukázal být spíše atrakcí než překážkou. Nejsem si jistý, že by to mohlo začít jinak.

On on cryptografické jádro, což je důvod, proč knihovna nese jeho iniciály. Já jsem převzal části, které promění knihovnu v něco, co mohou ostatní skutečně nasadit: integraci do aplikací, testování, dokumentaci a komunitní stránku. Aktivně jsem také hledal místa, kde se používá konkurenční šifrovací knihovna, a převáděl nebo nahrazoval ji. SSLtelnet, SSLftp, NCSA httpd a řada dalších balíčků byly mou prací, aplikace postavené na kryptografických algoritmech a protokolech, které Eric implementoval. Toto rozdělení nám umožnilo soustředit se na to, co nás skutečně zajímá, což je podle mě hlavní důvod, proč projekt pokračoval.

Být v Austrálii umožnilo vůbec najít řešení a ukázalo se, že mnoho dalších lidí mělo přesně stejný problém ze stejného důvodu. Něco, co bylo vytvořeno pro konkrétní požadavek zákazníka v Brisbane, se stalo užitečným pro všechny mimo Spojené státy a nakonec i pro mnoho lidí uvnitř nich.

Věděli jsme, čím se to stane? Ne. Nikdo si neplánuje budovat kritickou infrastrukturu. Kritická infrastruktura je to, co zjistíte, že jste postavili, o několik let později, když zjistíte, kdo na ní závisí. Mysleli jsme si, že řešíme problém před námi, a pak odpovídáme na otázky ostatních, kteří narazili na stejnou překážku. Část s odpovídáním na otázky se ukázala být stejně důležitá jako kód.

Pracujete v kryptografii a internetové bezpečnosti více než tři desetiletí. Co se během této doby nejdramatičtěji změnilo v oblasti hrozeb a které bezpečnostní problémy zůstaly překvapivě podobné navzdory obrovskému technologickému pokroku?

Největší změna spočívá v tom, že útoky na systémy se staly profesí s ekonomickým modelem. V polovině devadesátých let lidé, kteří vnikali do systémů, to dělali hlavně proto, že je to zajímavé. Dnes existuje průmysl se specializací, nástroji, dodavatelskými řetězci, zákaznickou podporou a v některých případech i státním financováním. To mění vše, jak musíte přemýšlet, protože už nebráníte jen zvědavosti, ale bráníte někomu s rozpočtem, termínem a obchodním případem.

Druhá změna je rozsah a závislost. Průměrná aplikace v roce 1995 byla něco, co jste napsali. Průměrná aplikace dnes je něco, co jste sestavili, a většina kódu v ní byla napsána lidmi, které jste nikdy nepotkali a neznáte. Útočná plocha se přesunula z vašeho kódu na vaše závislosti a většina organizací si toto neuvědomila.

Co zůstalo pozoruhodně konstantní, jsou způsoby selhání. Stále píšeme chyby v kódu, který zpracovává nedůvěryhodný vstup. Stále vydáváme systémy s výchozími nastaveními, která nikdo nepřezkoumal. Certifikáty stále expirují v sobotu. Přihlašovací údaje stále končí na místech, kde by neměly být. A kryptografie se téměř nikdy neporuší na úrovni matematiky. Je obcházená, špatně nakonfigurovaná nebo prostě vypnutá. Kdybyste mi dali seznam deseti hlavních příčin narušení z roku 1996 a seznam z minulého měsíce, těžko byste je od sebe odlišili. Technologie se kompletně proměnila. Chyby zůstaly.

OpenSSL 4.0 byl vydán v dubnu 2026, což představuje první významné vydání projektu po několika letech. Co nám toto vydání říká o budoucnosti kryptografické infrastruktury a které změny budou podle vás pro organizace, které na OpenSSL spoléhají, nejvíce podstatné?

Nejvíce užitečné, co je třeba o 4.0 pochopit, je to, že jde především o verzi s odečtením funkcí, a to byl její hlavní smysl.

Úplně jsme odstranili rozhraní ENGINE. Odstranili jsme SSLv3 a SSLv2 ClientHello. Zakázali jsme zastaralé eliptické křivky a explicitní EC křivky při kompilaci. Udělali jsme ASN1_STRING neprůhledným a zpřesnili řadu API signatur. To jsou změny, které vytvářejí práci pro vývojáře, a jsou to změny, které mají význam, protože kryptografická knihovna, která jen hromadí funkce, nemůže zůstat bezpečná. Každá zastaralá cesta kódu, kterou udržíte, představuje útočnou plochu, kterou někdo spravuje vaším jménem a nikdo ji nezkouší.

Jsou zde také novinky: Encrypted Client Hello, podpora RFC 8998 včetně hybridní skupiny SM2/ML‑KEM, cSHAKE, SNMP a SRTP KDF, vyjednaný FFDHE pro TLS 1.2. ECH konkrétně uzavírá skutečnou mezeru v soukromí, protože Server Name Indication uniká identitu každého navštíveného webu od doby, kdy byl nasazen TLS 1.3. Ale odstranění jsou tím hlavním příběhem.

Co bych organizacím chtěl nejvíce zdůraznit, je toto: 4.0 není LTS verze. Je podporována do května 2027. Současná dlouhodobě stabilní verze je 3.5, podporována do dubna 2030, a 3.5 již obsahuje postkvantové algoritmy. Pokud chcete nejnovější kód, použijte 4.0. Pokud chcete stabilní cíl, kolem kterého můžete vybudovat pětiletý migrační plán, použijte 3.5. Volba vyššího čísla jen proto, že je vyšší, je chyba, kterou vidíme u lidí každým cyklem.

Postkvantová kryptografie se posunula z výzkumného problému k migrační výzvě, přičemž OpenSSL již podporuje ML‑KEM, ML‑DSA a SLH‑DSA a hybridní postkvantovou výměnu klíčů. Pro obchodní lídry, kteří předpokládají, že kvantové počítače jsou ještě příliš vzdálené, jaká rizika dnes přehlížejí?

Nejčastější chybou je považovat to za otázku, kdy přijde kryptograficky relevantní kvantový počítač. To je špatná proměnná. Správná otázka je, jak dlouho musí vaše data zůstat důvěrná a jak dlouho bude trvat vaše migrace. Odečtěte druhé od prvního a získáte skutečný termín, a pro mnoho organizací je tento termín už v minulosti.

Šifrovaný provoz může být dnes zachycen a uložen na neurčito. Pokud má informace v něm dvacetiletý horizont citlivosti (zdravotní záznamy, osobní soubory, duševní vlastnictví, diplomatické materiály, finanční pozice), útočník nyní nepotřebuje kvantový počítač. Potřebuje ho nakonec a mezitím levné úložiště. To není spekulativní útok; je to rozhodnutí o archivaci.

Druhou přehlíženou věcí je, že migrace není jedním projektem. Výměna klíčů je snadná část a mnoho z ní se již děje: OpenSSL 3.5 učinil hybridní postkvantovou výměnu klíčů výchozím nastavením TLS, takže mnoho organizací již nyní používá postkvantové dohodnutí klíčů, aniž by o tom rozhodly. Podpisy a hierarchie certifikátů jsou obtížná část, protože zahrnují certifikační autority, hardwarové kořeny důvěry, klíče pro podepisování firmware, hardwarové bezpečnostní moduly a zařízení s patnáctiletou životností, která byla postavena na předpokladu, že RSA bude navždy fungovat.

Třetí věc je omezení, na které nikdo neplánuje rozpočet: postkvantové podpisy jsou velké. Podpis ML‑DSA‑65 je přibližně padesátkrát větší než podpis ECDSA P‑256 a SLH‑DSA je ještě větší. To rozbíjí věci: velikosti handshake, omezená zařízení, protokoly s pevně zakódovanými limity polí, satelitní a IoT spojení. Tyto problémy objevíte testováním, ne čtením standardu.

Jednou z výzev postkvantové migrace je, že organizace možná ani neví, kde všude je kryptografie používána v jejich aplikacích, infrastruktuře, zařízeních a závislostech třetích stran. Jak by měly společnosti přistupovat k inventarizaci kryptografie a kryptografické agilnosti, aby další velký přechod algoritmu se nestal nouzovou situací?

Začněte nepříjemnou pravdou: kryptografickou inventuru nelze vytvořit zasláním dotazníku vašim dodavatelům. Dostanete směs marketingových textů, upřímné nejistoty a odpovědí, které byly pravdivé před třemi verzemi. Říkám to po tom, co jsem nedávno strávil značné množství času čtením dokumentace hardwarových dodavatelů v souvisejícím oboru, a rozdíl mezi tím, co dokumentace tvrdí, a tím, co produkt skutečně dělá, je větší, než si většina kupujících představuje.

Musíte se podívat. Existují tři vrstvy a každá vyžaduje jiné techniky. Kód, který jste napsali: statická analýza, skenování závislostí a vyhledávání identifikátorů algoritmů, které jste před lety tvrdě zakódovali. Kód, který jste propojili: softwarové bill of materials, rozšířené na kryptografické bill of materials, kde je práce s CBOM skutečně užitečná. Věci, které jste zakoupili nebo připojili: pozorování sítě, protože to, co vaše systémy skutečně vyjednávají na drátě, je pravda a často to není to, co kdokoli věřil.

Co se týče agility, princip je jednoduchý a praxe nikoli: algoritmus by měl být rozhodnutím v konfiguraci, ne změnou kódu. Pokud změna šifry vyžaduje vývojáře, sestavení, testovací cyklus a vydání, nemáte agilitu. Máte projekt. Centralizujte kryptografické operace za rozhraní, které kontrolujete, aby existovalo jedno místo ke změně místo čtyř stovek.

A pak část, kterou téměř všichni přeskočí: vyzkoušejte ji. Agilita, kterou jste nikdy nepoužili, je tvrzení, ne schopnost. Vyberte si klidný víkend, vypněte algoritmus v neprodukčním prostředí a zjistěte, co selže. Něco selže. Je lepší to objevit ve vašem plánu než během povinné nouzové migrace.

Užitečnou vynucovací funkcí je životnost certifikátů. Průmysl přechází na výrazně kratší životnost certifikátů, což dělá ruční správu certifikátů neudržitelnou a nutí automatizaci, kterou jste stejně potřebovali. Pokud správně automatizujete vydávání a rotaci certifikátů, vytvořili jste většinu mechanismů, které bude budoucí přechod algoritmu vyžadovat.

AI mění jak obranu v kybernetické bezpečnosti, tak schopnosti útočníků. Kde podle vás AI skutečně mění bezpečnostní rovnici a kde si myslíte, že organizace příliš soustředí na technologii a přitom přehlíží základnější slabiny?

AI skutečně mění jednu věc a mohu o tom mluvit přímo, protože se to nám stalo.

Významná část zranitelností zveřejněných v OpenSSL letos byla nalezena analýzou řízenou AI. V lednu jsme vydali verzi, která opravila dvanáct problémů, prakticky všechny od jedné výzkumné skupiny používající automatizovanou analýzu, a přispěli patchemi spolu s hlášením. V červnu jsme opravili vysoce závažný use-after-free v ověřování PKCS#7, který našel výzkumník pracující s AI systémem. To je skutečná změna schopnosti nacházet chyby v paměťové bezpečnosti a parsování v zralém C kódu, který byl po léta kontrolován experty. Viděl jsem stejný vzor i v jiných kryptografických knihovnách. Analýzou šarže CVE Bouncy Castle z tohoto roku je otisk automatizované analýzy kódu jasný.

Zřejmý důsledek je, že to funguje obousměrně. Stejné techniky jsou k dispozici komukoli, kdo je chce použít, na stejných kódech, a obránci nemají výlučný přístup.

Méně zřejmý důsledek, který zdůrazňuji, je zátěž, kterou to klade na správce. Vytvoření věrohodné zprávy o zranitelnosti je nyní téměř zdarma. Její třídění už není. Stále to stojí lidského experta v reálném čase. Týmy pro bezpečnost open source, které jsou obvykle malé a často dobrovolnické, absorbují rostoucí objem zpráv s velmi proměnlivou kvalitou. Dobré, jako výzkum, který jsem zmínil, přicházejí s reproduktory a patchemi. Špatné jsou útok typu denial-of-service na lidi, na které spoléháte. Pokud vaše organizace nasazuje AI proti open source kódu, financujte kapacitu třídění na druhé straně.

Kde podle mě směřuje pozornost špatně: AI neaktualizuje vaše systémy. Neinventarizuje vaše aktiva, neotáčí vaše přihlašovací údaje, neodstraňuje nepodporovaný hardware ani nevyžaduje odpovědnost za certifikát, který expiruje příští měsíc. Organizace, které kupují AI bezpečnostní nástroje a zároveň provozují software se známými neopravenými zranitelnostmi, mají špatné pořadí. Nezářící práce je stále tam, kde je riziko.

Mnoho organizací investuje značně do nástrojů, ale zůstává zranitelných kvůli konfiguračním chybám, zastaralým systémům, slabým procesům nebo špatné přípravě na incidenty. Jaké jsou nejzávažnější bezpečnostní chyby, které stále vidíte, a co by měly mít vedení organizací připravené ještě před tím, než k útoku dojde?

Nejzávažnější chybou je považovat bezpečnost za nákupní aktivitu. Nástroje jsou zakoupeny, rozpočty splněny, dashboardy jsou zelené a nikdo se nezeptal, zda organizace skutečně dokáže provádět základní úkony.

Druhou chybou je neznát, co provozujete. Nemůžete opravovat software, o kterém nevíte, že jej máte, a většina organizací odhalí skutečný obsah svého majetku během incidentu. Proto je práce s bill-of-materials důležitá, ne jako artefakt shody, ale jako něco, na co sáhnete ve dvou ráno, když spadne kritické upozornění a někdo se zeptá, zda jste zasaženi.

Třetí jsou výchozí nastavení. Systémy jsou nainstalovány, fungují a konfigurace se nikdy nezkoumá. O pět let později je tato konfigurace závazkem a nikdo, kdo se podílel na původním rozhodnutí, už tam nepracuje.

Čtvrtá je správa klíčů a certifikátů ponechaná jednotlivcům. Pozoruhodná část výpadků způsobených vlastními chybami jsou expirující certifikáty, které jeden člověk tiše sledoval v tabulce, dokud nezměnil práci.

Před incidentem potřebuje vedení čtyři věci. Jmenovaného rozhodovatele s pravomocí vypnout podnik, rozhodnutého předem a písemně, protože argument o tom, kdo má tuto pravomoc, není něco, co chcete řešit v reálném čase. Již podepsané smlouvy s externími forenzními a specialistickými poradci, protože tato zakázka trvá týdny a vy budete mít jen hodiny. Komunikační kanál, který nezávisí na systémech, jež mohou být kompromitovány. A schopnost obnovy, která byla skutečně testována od začátku do konce, ne jen záložní režim ověřený pouze tím, že úlohy úspěšně skončily.

Pak to procvičte. Cvičení na stole na úrovni vedení, jednou ročně, odhalí více skutečných mezer než další nástroj.

Když dojde k vážnému kybernetickému útoku, výkonný management může najednou čelit technickým, právním, provozním a komunikačním rozhodnutím pod obrovským tlakem. Co odlišuje organizace, které reagují efektivně, od těch, které umožní incidentu výrazně se zhoršit?

Organizace, které to zvládnou dobře, učinily důležitá rozhodnutí před incidentem, takže během incidentu provádějí akce místo úvah. To je podstatná část.

Kromě přípravy je několik věcí, které konzistentně oddělují dobré reakce od špatných.

Oddělují technické vyšetřování od výkonného a komunikačního proudu, s definovaným rozhraním mezi nimi. Když stejní lidé snaží se omezit průnik a připravit oznámení zákazníkům, oba úkoly jsou provedeny špatně.

Zachovávají důkazy před nápravou. Instinkt okamžitě přestavět kompromitovaný stroj je silný a ničí informace potřebné k určení rozsahu. Pokud nedokážete odpovědět „co dalšího se dotkli“, nemůžete věrohodně říci, že incident je ukončen.

Přijímají, že počáteční informace jsou předběžné, a komunikují tomu odpovídajícím způsobem. Většina poškození reputace, kterou jsem pozoroval, nepřišla z narušení, ale z jistých počátečních prohlášení, která musela být stažena. Říci „toto víme, toto zatím nevíme, toto je, kdy vás budeme informovat“ není slabost. Je to jediná pozice, kterou nebudete muset měnit.</