Certifikáty PKI (Public Key Infrastructure) používané například v HTTPS jsou pro nás velmi užitečné a zajišťují důvěryhodnost spojení mezi klientem a serverem. Někdy se ovšem stane, že se certifikát v průběhu své životnosti stane nedůvěryhodným. Nejčastěji tak, že nám unikne soukromý klíč, který tvoří pár s veřejným klíčem zapsaným v certifikátu.
V takové situaci potřebujeme certifikát revokovat, tedy zneplatnit před doběhem jeho platnosti. Požadavek je to logický, ale jeho technické zajištění je obtížnější, než by se mohlo na první pohled zdát. Historicky byly k tomuto účelu nasazovány dva různé mechanismy: revokační seznamy (CRL) a protokol OCSP (Online Certificate Status Protocol). Oba mají bohužel své stinné stránky.
CRL a OCSP
CRL je v zásadě jednoduchý seznam certifikátů, které už nemají být považovány za platné. Tento seznam vytváří certifikační autorita a klient si jej může stáhnout z předem známé URL. Seznam je opatřen elektronickým podpisem autority, takže jeho pravost je ověřitelná. Problémem těchto seznamů je jejich velikost.
Certifikáty na nich musejí být totiž uvedeny po celou dobu své původní platnosti, takže tyto seznamy mohou narůstat do velikosti desítek megabajtů pro jednu autoritu. Používání seznamů je tedy velmi neefektivní, protože prohlížeč musí stahovat stovky megabajtů záznamů. Na mobilních zařízeních je tohle chování naprosto nepřípustné.
Proto vznikl protokol OCSP, který vlastně vytváří samostatný jednopoložkový seznam CRL pro každý certifikát zvlášť. Pokud tedy klient chce ověřit platnost konkrétního certifikátu, stačí mu kontaktovat službu OCSP dané autority a vyžádat si právě tento jeden záznam o platnosti. Ten je malý (zhruba sto bajtů), je opatřen podpisem a má delší časovou platnost (obvykle týden). Toto okamžité ověřování ale vyžaduje, aby byl odpovídač OCSP (responder) vždy dostupný.
Co má klient udělat, pokud nemůže z nějakého důvodu získat informaci o platnosti? Má považovat certifikát za neplatný? V takovém případě by ovšem výpadek OCSP znepřístupnil spoustu webů. Prohlížeče tedy raději zvolily konzervativnější metodu, žádnou odpověď považují za dostatečnou a neprotestují při ní.
Pokud vám tedy útočník zabrání v přístupu k OCSP, nedozvíte se o revokaci a uniklý soukromý klíč může být použit na falešném webu proti vám. I když ale vše funguje jak má, není OCSP ideálním řešením. Kvůli snížení zátěže mají totiž revokační zprávy (SCT, Signed Certificate Timestamp) dobu platnosti v řádu týdne. Tak dlouho bude trvat, než se klient znovu autority zeptá, zda se stav nezměnil. Po tu dobu může útočník neplatný certifikát dál zneužívat.
Ještě horší je, že klient kontaktuje autoritu při každém navštívení nového webu. To klienta zdržuje a zároveň má certifikační autorita přehled o tom, kdo navštěvuje které weby. Zlá autorita by tak mohla sledovat vaše chování na webu. Není divu, že ani tahle metoda se v praxi příliš neosvědčila a tvůrci prohlížečů ji postupně opustili.
Výsledkem je, že revokace je už dlouho rozbitá. Žádné z řešení totiž není dostatečně dobré: seznamy CRL jsou neefektivní a protokol OCSP je zase nespolehlivý. Potřebujeme něco lepšího.
CRL znovu a lépe v režii prohlížečů
Prohlížeče v poslední době vsadily na vlastní řešení, kterým je šíření vlastních CRL vlastními kanály. Jednotliví tvůrci tomu říkají různě: Mozilla to nazývá CRLite a Google zase CRLSets. Princip je ale totožný: místo stahování obrovských seznamů do každého prohlížeče u každého uživatele si seznamy centrálně stahuje tvůrce prohlížeče.
Velký balík dat pak převede do velmi efektivního Bloomova filtru. Ten z 300MB databáze certifikátů udělá malý souhrnný objekt o velikosti 1 MB. Podle něj je ale stále možné ověřit, zda certifikát s daným identifikátorem v množině je či není. Tento malý objekt je pak distribuován předem připraveným mechanismem zabudovaným do prohlížečů. Firefox například aktualizuje data každých šest hodin.
Toto řešení má všechny výhody předchozích dvou. Informace o revokacích jsou stahovány dopředu a nezdržují pak načítání jednotlivých stránek, zároveň jsou ale velmi malé a nezatěžují linku a úložiště. Ověřování pak probíhá lokálně v uživatelově počítači, nemusí se čekat týden na vypršení platnosti odpovědi a informace o navštěvovaných webech neputují k autoritě.
Certifikační programy Apple a Mozilly vyžadují, aby nejpozději k 1. říjnu 2022 všechny autority zavedly podporu seznamů CRL. Konkrétně je požadováno, aby vznikl jeden či více seznamů pokrývajících všechny certifikáty revokované danou autoritou. Adresy těchto seznamů pak musejí být zveřejněny v databázi CCADB (Common CA Database). Safari a Firefox pak budou moci zavést již přislíbenou podporu souhrnných CRL, které pak budou distribuovat uživatelům.
Let's Encrypt
V současnosti nejpopulárnější certifikační autorita Let's Encrypt se na podporu již delší dobu připravuje. Při spuštění v roce 2015 bylo rozhodnuto, že autorita bude podporovat pouze OCSP, protože tento způsob revokací byl v danou chvíli jediný povinný. Nyní nastal čas začít podporovat CRL a nástroje pro to už vznikly a jejich zdrojové kódy jsou k dispozici.
Autorita uvádí, že v každém okamžiku je na světě 200 milionů platných certifikátů od Let's Encrypt. Kdyby měly být všechny naráz revokovány, měly by jejich seznamy dohromady přes 8 gigabajtů. Aby nebyl výsledek příliš těžkopádný, jsou data rozdělena do 128 samostatných souborů, přičemž každý bude mít v nejhorším případě snesitelných 70 megabajtů.
Odkazy na tyto seznamy ale kvůli velikosti nebudou součástí certifikátů a najdeme je pouze ve zmíněné CCADB. V certifikátech zůstanou odkazy na OCSP, takže klient bude moci stále ověřit stav individuálního certifikátu, pokud to bude potřebovat. Mozilla a Apple ale budou moci převzít celou zátěž se stahováním a zpracováním velkých seznamů.
Je to docela nadějný způsob, jak revokaci řešit systematicky a přitom pro uživatele příjemně. Obavy o soukromí ale zmizí, až všichni přestanou používat OCSP. Výše zmíněné řešení je zatím funkční jen pro prohlížeče, existuje ale spousta dalších programů, které na certifikátech závisejí. Dalším krokem tedy bude vymyslet, jak potřebné informace spolehlivě dostat také do nich.
Další čtení
- Scott Helme: Revocation is broken
- Let's Encrypt: A New Life for Certificate Revocation Lists
ČLÁNKY DO MAILU