Povinnost zveřejňovat všechny veřejné certifikáty v databázích Certificate Transparency (CT) je tu s námi od jara loňského roku. První logy ale vznikly ještě o několik let dříve a jejich použití bylo pro některé autority povinné už dříve. Let's Encrypt na začátku letošního roku slíbil, že spustí vlastní logy pro CT a skutečně se tak stalo.
Stručně řečeno je CT databáze, do které jsou přijímány certifikáty veřejně důvěryhodných autorit. Jsou organizovány do Merklova stromu ověřitelného pomocí elektronického podpisu. Záznamy jsou veřejně dostupné a je možné v nich libovolně vyhledávat. Protože prohlížeč vyžaduje, aby k certifikátu bylo doloženo také digitálně podepsané potvrzení o přidání do logu, jsou všechny autority nuceny vystavované certifikáty tímto mechanismem zveřejňovat. Jinak jsou neplatné. Podrobně se o tom dočtete v samostatném článku.
Certifikační autorita Let's Encrypt nyní zveřejnila podrobnosti o tom, jak provozuje svůj log. Není to úplná maličkost a lidé stojící za projektem doufají, že nabídnou inspiraci těm, kteří by chtěli podobný projekt provozovat.
Milion certifikátu denně
Let's Encrypt dnes vystavuje více než milion certifikátů denně a toto číslo neustále roste. Log pro jejich ukládání ovšem musí pojmout i případné certifikáty dalších autorit, takže je potřeba jej dostatečně nadimenzovat a umožnit další škálování v budoucnu. V současné době se počítá se dvěma miliony certifikátů denně.
Jsou tu ale i další požadavky, například je potřeba zajistit vysokou dostupnost infrastruktury. Uptime musí být vyšší než 99 % a žádný výpadek nesmí být delší než 24 hodin. Kvůli tomu je dobré také velký log rozdělit na několik menších. Tohle celé navíc musí být pokud možno bezobslužné, protože odborná lidská práce je drahá.
Kvůli testování jsou ale vlastně provozovány dva separátní logy: produkční a testovací. Oba jsou pod plnou zátěží, takže jakýkoliv výkonnostní problém s novou verzí by se projevil v testovacím prostředí dříve, než by byl stejný software nasazen do produkce. Všechny novinky se samozřejmě nejprve vyzkoušejí a pak se dostanou na ostré servery.
Amazon Web Services (AWS)
Infrastruktura logů běží v AWS a hlavním důvodem je, že Let's Encrypt chce zachovat diverzitu poskytovatelů. Logů není příliš mnoho a pokud by jich kvůli selhání jedné podpůrné infrastruktury vypadlo několik najednou, mohlo by to znamenat nepříjemný problém.
Když se rozhodovalo o umístění logu Let's Encrypt, běžely některé další na infrastruktuře Google a také v Digital Ocean. Proto bylo rozhodnuto, že v rámci rozložení rizika bude nový log spuštěn právě na AWS. Zajímavé je, že log společnosti Digicert běží na stejné infrastruktuře.
Druhou výhodou AWS je, že z hlediska této aplikace podporuje všechny potřebné vlastnosti a tým Let's Encrypt má s tímto poskytovatele předchozí zkušenosti. Podle všeho neexistovaly prakticky žádné pochybnosti o tom, že půjde o dobrou volbu.
Terraform, MariaDB a Kubernetes
Základním stavebním kamenem je Terraform, který umožňuje velmi rychle nasadit komplexní infrastrukturu a poté ji snadno spravovat. Protože Let's Encrypt používá Terraform v mnoha dalších oblastech, bylo možné velkou část původního řešení použít také pro CT log. Infrastruktura používá zhruba 50 různých komponent a díky Terraformu je možné se o ni starat i s velmi malým týmem. Automatizace navíc umožňuje snadno škálovat, testovat a vyhýbat se konfiguračním chybám.
Druhým důležitým prvkem je databáze. Tady byla zvolena MariaDB, kterou Let's Encrypt používá ve své certifikační autoritě. Databáze běží v Amazon Relational Database Service (RDS), která nabízí synchronní replikaci i na záložní stroje. To umožňuje automatický přechod do záložního režimu v případě selhání. Výsledkem je zachování konzistence, která je při provozu CT logu zásadní. Jediný neuložený certifikát totiž může znamenat nepříjemný výpadek a může vést k vyřazení logu ze seznamu důvěryhodných. RDS tohle všechno výrazně zjednodušuje, přesto se musí vývojáři starat o ladění výkonu a monitoring databáze.
Odhaduje se, že bude potřeba 1 TB prostoru pro 100 milionů certifikátů. Zároveň se předpokládá, že log bude muset každý rok uložit miliardu certifikátů a precertifikátů. To bude znamenat 10 TB dat uložených do databáze každý rok. Aby se ušetřily náklady, bude každý rok databáze zmrazena a přesunuta na levnější úložiště. To hlavní má dvakrát 12 TB replikovaných pomocí zmíněného RDS. Každá instance má přitom 8 procesorových jader a 128 GB RAM.
Třetím nosným pilířem je Kubernetes, který umožňuje pohodlně nasazovat a spravovat instance jednotlivých aplikací. S nasazením Kubernetes neměli předtím správci žádné zkušenosti, ale využili tuto příležitost k jejich nabytí. Plánují, že se v budoucnu stejné postupy rozšíří také do dalších částí projektu.
Řídicí část prostředí Kubernetes běží v Amazon Elastic Kubernetes Service (EKS) a samotné uzly běží na čtyřech instancích EC2 s 8 jádry a 16 GB RAM.
Software pro CT log
Na celé této infrastruktuře pak běží samotný software, který se stará o provoz celého logu. Základem je Certificate Transparency Front End, zkráceně CTFE. Ten je otevřený směrem k uživatelům a nabízí jím rozhraní podle RFC 6962. Zároveň překládá požadavky na požadavky gRPC API pro Trillian.
Trillian je obecné úložiště kryptograficky verifikovatelných dat. Implementuje úložiště pomocí Merklova stromu, což se výborně hodí právě pro využití v CT logu. Skládá se ze dvou částí: log signer a log server. Ten první přijímá nekonečný proud příchozích dat a zařazuje je do stromu. Druhý se pak stará o vyzvedávání dat při nahlížení do logu.
Load balancing a monitoring
Provoz vstupuje do Amazon ELB a ten je mapován na službu Kubernetes Nginx Ingress. Ta umožňuje rozkládat zátěž mezi několik uzlů (podů) s Nginx. Tyto uzly fungují jako proxy a předávají dotazy do služby CTFE, která je opět vyřizuje na některém z uzlů. Už na úrovni Nginx je přitom aplikován rate limiting dle IP adres a user agenta.
Trillian a CTFE exportují své metriky do nástroje Prometheus, ze kterého je pak možné získávat přehledné nástěnky (dashboard) se stavem celé infrastruktury a na základě problémů generovat varování pro operátory. Pro monitoring celého logu se pak používá nástroj ct-woodpecker, který vyvinuli přímo vývojáři Let's Encrypt. Ten je spouštěn mimo hlavní infrastrukturu pro provoz logu.
Kudy dál
Tvůrci Let's Encrypt mají samozřejmě další plány na vylepšení svého řešení. Chtějí například snížit zátěž na databázi Trillianu tím, že budou automaticky objevovat a vyřazovat duplicitní záznamy. Do databáze se totiž ukládají celé řetězce důvěry, tedy i obrovské množství stejných mezilehlých certifikátů.
V rámci snížení nákladu se také chtějí podívat na to, zda by nebylo možné využívat levnější úložiště. Stejně tak by rádi prozkoumali, zda by nebylo možné zmenšit velikost instancí Kubernetes nebo použít více menších instancí v EC2.
