V letech 2011 až 2012 došlo k několika průnikům do různých certifikačních autorit (CA), jejichž výsledkem byly podvodem vydané certifikáty. Tím vznikla potřeba nežádanou situaci řešit. Vzniklo poměrně mnoho nápadů a implementací, které buď časem dožily nebo tak různě přežívají. Pro úplnost seznam:
- Perspectives – nejstarší, využívá síťovou perspektivu od „notářských serverů“
- Convergence – jako Perspectives, jen trochu více privátnější, požadavky jdou přes jednu proxy
- Sovereign Keys – myšlenka záznamu všech certifikátů, lze jenom přidávat, ne odebírat (nikdy nebyl napsán žádný kód)
- DANE – pinování klíčů a certifikátů v DNS stromu s pomocí DNSSEC
- podpisování certifikátu od více CA – nikdy se nedošlo dále než k myšlence
- TACK – rozšíření TLS protokolu, IETF draft protokolu expiroval
- HTTP public key pinning (HPKP) – trust-on-first-use pinování v HTTP protokolu
Je toho celkem hodně (je klidně možné, že jsem na něco zapomněl). Dnes z tohoto seznamu funguje snad jen Perspectives (komunita přidala notářské servery), DANE a možná se začne používat HPKP. Perspectives má nevýhodu u serverových farem jako Google, uživatel nepozná podvržený certifikát, protože legitimních certifikátů jsou stovky. HPKP je určeno jen pro HTTPS a nelze ho použít pro jiný protokol. DANE vyžaduje od zóny zavedení DNSSEC, k němu se ale velcí poskytovatelé služeb moc nemají. Certificate Transparency není úplně nový, ale prosazuje ho Google a jak víme, ten má ostré lokty.
Myšlenkově vychází Certificate Transparency (CT) ze Sovereign Keys. Jde o to mít „append-only“ záznam certifikátů mirrorovaný na různých serverech – lze jen přidávat, ale ne odebírat. Časem se přidaly vlastnosti jako možnost cenzurovat části doménového jména – zjevně ne každý chce zveřejňovat názvy počítačů ve své síti.
CT ukládá do svých logů jen samotné certifikáty, ale ne už, u jakého DNS jména stroje byly nalezeny, jak je to u Perspectives.
Hlavní rozdíl CT je oproti protokolu DANE v tom, že u DANE operátor serveru určuje, které certifikáty můžou jeho servery používat. U CT jde více o transparentnost vydávání certifikátu a možnosti přijít na „falešnou hru“, při níž byl certifikát vydán proti pravidlům (napadením nebo donucením CA).
Google prohlašoval, že pokud certifikační autority neimplementují Certificate Transparency ve svém procesu vydávání certifikátů do února 2015, tak ztratí EV bit v Chrome (Extended Validation, který způsobuje „zelený adresní řádek“). To se ale nestalo, a tak prakticky jediná větší certifikační autorita implementující CT je Digicert. Seznam veřejných logů lze nalézt v zatím celkem krátkém seznamu. Za zmínku stojí speciální logy provozované Googlem, ty sbírají všechny certifikáty, které jejich crawler někdy viděl.
I když první RFC 6962 specifikující Certificate Transparency existuje již od roku 2013, pořád se pracuje na náhradě 6962-bis, která má některé technické detaily upravit a ujasnit. Z klientské strany má zatím částečnou podporu pro Certificate Transparency implementovanou jen Chrome, pokud nepočítáme referenční implementaci.
Log certifikátů
Nejdůležitější datovou strukturou v CT je Merklův hashový strom, v něm jsou všechny certifikáty uloženy jako listy. Do stromu lze jen přidávat, nikdy odebírat. Kořen stromu je podepsán, čímž je zaručena integrita. Tento strom se taky nazývá log certifikátů.
Log lze s mírnou nadsázkou přirovnat k blockchainu v Bitcoinu. Strom obsahuje vydané certifikáty, v kterých lze vyhledávat. Samotné struktury logu jsou uloženy na logserverech, které jsou veřejné a lze je mirrorovat. Každý logserver specifikuje maximální prodlevu, jak dlouho bude trvat, než se přidaný certifikát v logu objeví (typicky se používá den).
Do logu logserveru může certifikáty přidávat kdokoliv. Podmínka je, aby se řetězily k nějaké sadě kořenových certifikátů, které log uznává – je to především ochrana před zahlcením.
Role jednotlivých hráčů v Certificate Transparency
Role, které známe z běžného nasazení TLS, jsou provozovatel koncového serveru, CA která k němu vydala certifikát a uživatel připojující se k serveru. CT přidává tyto role:
- monitor – někdo, kdo sleduje ostatní logy, zda se chovají správně a zda tam nepřibývají „špatné“ certifikáty
- auditor – někdo, kdo kontroluje jen část logu nebo konkrétní certifikát (typicky webový prohlížeč)
- aplikace třetích stran – pro extra funkcionalitu – třeba hezčí API dovolující lepší vyhledávaní v lozích
Je zpracován i rozsáhlejší dokument analyzující hrozby, proti kterým má CT chránit.
Jak log funguje
V procesu vydávání certifikátu přibyl krok navíc – CA musí vložit informace o certifikátu do CT logu, a to předtím než vydá samotný certifikát zákazníkovi. Nový způsob vydání certifikátu od CA bude vypadat následovně:
- zákazník požádá o nový certifikát pro server
- CA vytvoří precertifikát odpovídající novému serverovému certifikátu
- CA zaloguje precertifikát u logserveru. Na důkaz, že to provedla, dostane od logserveru nazpět Signed Certificate Timestamp (SCT)
- CA vydá zákazníkovi SSL/TLS certfikát obsahující SCT jako X.509v3 rozšíření
- zákazník použije tento SSL/TLS certifikát obvyklým způsobem – nainstaluje si jej na svůj server
Signed Certificate Timestamp je zjednodušeně řečeno podepsané časové razítko dokladující, že certifikát byl přidán do logu. V předchozím postupu vydávání certifikátu jsme použili výraz precertifikát, který označuje TLS certifikát ořezaný o podpis a některá rozšíření (jinak by se proces zacyklil – bylo by nutno změnit podpis certifikátu, tím pádem změnit SCT, což by opět ovlivnilo podpis certifikátu…).
Z klientské strany přibylo kromě ověřování řetězců certifikátů ještě ověření SCT:
- prohlížeč nejprve zkontroluje řetězec certifikátů, jako obvykle
- prohlížeč navíc zkontroluje, že SCT v certifikátu byla zaznamenána v nějakém logu, ověří podpis SCT
- pokud všechno proběhlo v pořádku, pokračuje se dále v TLS/SSL spojení
Signed Certificate Timestamp je podpis struktury obsahující:
- timestamp kdy k podpisu došlo
- ID logu, který SCT vydal
- precertifikát nebo X.509 certifikát
Jak Certificate Transparency otestovat
Než se pustíme do technických detailů, ukažme si, jak lze CT vlastně použít. V Chrome prohlížeči je na to miniaturní GUI, které ale moc neřekne, je jen takové provizorní.
Mnohem zajímavější je vyhledávač crt.sh v CT lozích. Upozornění: jak jsem psal, CT nezaznamenává, u jakého stroje byl certifikát nalezen, jen certifikát samotný. Tudíž vyhledávaní nemusí fungovat úplně správně pro jména, v jejichž případě je certifikát vydán na „wildcard“ jméno (s hvězdičkou).
Ověření platnosti Signed Certificate Timestamp
Prohlížeč nejprve ověří podpis samotného SCT. Veřejné klíče známých logů jsou v prohlížeči předinstalovány. Prohlížeč pak ze SCT a certifikátu odvodí hash listu, který se používá jako vyhledávací klíč do API logserveru. Logserver odpoví se seznamem hashů, které vedou v Merklově stromě ke kořenu – je to důkaz zařazení certifikátu ve stromě (tzv. audit path). Příklad na obrázku ukazuje, co se stane, pokud bychom chtěli důkaz zařazení certifikátu d3:
Důkaz zařazení certifikátu
V Merklově stromě je hodnota rodiče hashem zřetězení potomků, tj. v příkladu m = hash(i || j). Důkazem zařazení jsou hashe uzlů, které nám chybí k dopočtení kořenového hashe. Důkaz zařazení certifikátu d3 ve stromě jsou hashe c, i, n. Je to z důvodu, že hash listu d spočteme snadno protože máme SCT a d3, z c||d spočteme j, z i||j spočteme m a z m||n spočteme kořenový hash.
Prohlížeč má teď kořenový hash, zeptá se logserveru, jaký kořenový hash vidí on. Logserver vrátí podepsaný kořenový hash (signed tree head), prohlížeč si tudíž může ověřit, že souhlasí s kořenovým hashem, ke kterému se dopočítal. Prohlížeč navíc ověří podpis kořenového hashe, protože veřejný klíč příslušící logserveru zná.
Ověření konzistence mezi dvěma stromy
Protože certifikáty v logu logserveru neustále přibývají, mění se i kořenový hash stromu. Monitory si průběžně přidávají nové části stromu z logserverů. Mezi starým podepsaným kořenem stromu a novým podepsaným kořenem stromu je potřeba ověřit konzistenci.
Pokud má monitor staženo po hash m, důkaz konzistence mezi dvěma kořeny stromu (původním a novým) provede podobně jako v předchozím případě u ověření, že SCT náleží do stromu: zeptá se logserveru na důkaz konzistence mezi dvěma kořeny.
Důkaz konzistence mezi starým a novým kořenem stromu
Výsledkem dotazu je opět seznam chybějících hashů, aby se mohl monitor ze starého kořenového hashe dopočítat k novému kořenovému hashi. Na obrázku výše by jako důkaz stačil jen hash k, protože ze starého hashe kořenu m a hashe k lze dopočítat nový kořen stromu.
Nepříjemné vlastnosti
I když původní myšlenka je velmi jednoduchá, implementačně je CT velmi náročné. Je to asi první protokol, který vyžaduje v rámci svého provozu certifikáty nejen parsovat, ale mazat nebo přidávat X.509v3 rozšíření a ověřovat podpis před nebo po této operaci. Klientovi může dojít SCT až třemi způsoby – jako X.509v3 rozšíření certifikátu, jako rozšíření TLS protokolu v TLS handshake nebo jako součást OCSP odpovědi.
De facto se vyžaduje, aby si vlastník domény hlídal pomocí monitoru nebo služby třetí strany, zda někdo nevydal špatný certifikát pro jeho doménu (je to obráceně než u DANE).
Monitor musí stahovat celý strom z logserveru nebo rozdíl od posledního známého kořene. Na „lehkotonážní“ použití, třeba jen kontrolu několika domén, to vyžaduje použití služby třetí strany. V logu lze vyhledávat jen pomocí SCT, ne podle doménového jména. Pro ilustraci, logy Googlu mají každý velikost kolem 75 GB. Zde je vidět, proč budou služby třetích stran jako crt.sh důležitou součástí CT ekosystému.
Necháme se překvapit, jak bude pokračovat přijímání a implementace CT protokolu mezi webovými prohlížeči a dalšími klienty.
