Let's Encrypt zítra revokuje 3 miliony certifikátů

Vypozoroval nekdo presny vzorec, za jakych podminek LE vydala certifikat se spatnym overenim CAA? Myslim tim napr. kombinaci vice TLD domen v jednom certifikatu, chybejici CAA pro nejaky alias, CNAME jako alias v certifikatu nebo tak?

Mne se tykalo pouhych osm z asi "tisice" certifikatu, jinak byly v poradku a na ty konkretni kombinaci podminek jsem neprisel.

CAA záznam se ověřoval pouze pro první doménu v certifikátu a ostatní ne

Co mate na mysli pod pojmem "domena"? DNS jmeno/alias v certfikatu?

Vetsina mych certifikatu ma vice nez jedno domenove jmeno, ale revokovany byl jen zlomek z nich

Týkalo se to jen těch certifikátů, které byly vydány déle než 8 hodin po validaci držení doménového jména. V tom okamžiku bylo nutné udělat revalidaci CAA záznamů a v ní byla chyba. Pokud jste stihl vystavit certifikát do 8 hodin po validaci, chyba vás nepostihla (validace byla OK, revalidace ne).

Podle zprávičky jsem to pochopil tak, že jde o certifikáty, které jsou pro více domén a navíc k ověření došlo po více než 8 hodinách. První ověření bylo v pořádku, problém byl při opakovaném ověření.
Je-li to skutečně tak, majitelé certifikátů nemají z čeho poznat, zda u daného certifikátu nastal problém.

Je to přesně tak. Typicky bude asi problém u certifikátů, kde byla přidávána nová doménová jména: V čase t=0 zvalidujeme jména A, B a C a vydáme první certifikát. Ten je v pořádku. Pak v čase 8h < t < 30 dnů chceme přidat jméno D. To se zvaliduje nově, ale pro jména A, B a C je validace platná, tak dojde pouze ke znovuověření CAA záznamů. A v tomto procesu byla chyba, takže takovýto certifikát je/bude revokován.

Mě osobně zastihly tři e-maily v 17:50. Certifikáty měnit zatím nebudu, docela mě zajímá, jak se prakticky projeví ta revokace.

Diky, tuhle informaci jsem nedokazal nikde najit.

> Mě osobně zastihly tři e-maily v 17:50. Certifikáty měnit zatím nebudu, docela mě zajímá, jak se prakticky projeví ta revokace.

odvazlivec ;-) tak dej vedet, jak to dopadlo.

tak jak se revokace projevily? vydaji zjistene poznatky na kratky clanek nebo nikoliv, protoze to vsude funguje jak ma?

K revokaci nakonec úplně nedošlo, aspoň u mých tří certifikátů ne. Napsal jsem o tom další zprávičku, vydržte. ;)

U mě se to týká i domén bez CAA záznamu a klasickou HTTP validací.

Způsob validace na to neměl vliv. Že nemáte CAA záznam tuhle chybu neovlivnilo – problém byl v tom, že certifikační autorita některé CAA záznamy vůbec neověřovala. To, že CAA záznamy nemáte teď, ale neznamená, že jste je tam nemohl mít v okamžiku, kdy to LE měla ověřit a neověřila.

Snažil jsem se to ve zprávičce popsat, asi neúspěšně :-)

Normální postup je, že dáte požadavek na validaci toho, že vlastníte doménu (uložení souboru na webový server, TXT DNS záznam). Tohle je validace v rámci ACME protokolu a u Let's Encrypt platí 30 dní. V rámci této validace se kontrolují i CAA záznamy – zda je vůbec Let's Encrypt oprávněna vydávat pro tyto názvy certifikát. Tahle validace byla přidána dodatečně a je to požadavek prohlížečů.

Obyčejně krátce po provedení validace necháte i vytvořit certifikát, a pak je vše OK. Někdy ale může nastat prodleva, ten certifikát nenecháte (z jakéhokoli důvodu) vystavit hned – máte na to těch 30 dní. (Nejčastějším důvodem asi bude to, že přidáváte na certifikát novou doménu – využijete toho, že ostatní jsou ještě validované a zvalidujete jen tu novou.) Jenže na kontrolu CAA záznamů jsou přísnější pravidla, kontrola při vydání certifikátu nesmí být starší, než 8 hodin (předpokládám, že je to pravidlo CA fóra). Takže když využijete třicetidenní lhůtu pro vydání certifikátu, kdy je platná validace, ale překročíte 8 hodin od validace CAA záznamů, musí se validace CAA záznamů provést znova (před samotným vydáním certifikátu). A v kódu Boulderu pro tuhle revalidaci byla chyba – sice se správně roztočila smyčka pro počet domén, které je potřeba validovat, ale v té smyčce se nebrala další a další doména, pracovalo se pořád jen s tou první. Takže když jste požadoval certifikát pro X domén, místo toho, aby se ověřilo znova těch X domén, ověřila se jen první doména ze seznamu, za to X-krát. (Neřešil bych, která byla ta první – je to chyba v programu, ty domény teoreticky mohou být uložené v nějaké struktuře, která nedrží pořadí prvků, takže první může být náhodná doména. Nevím, jak to bylo reálně, zda to byla třeba první doména uvedená v SAN žádosti.)

Tedy netýkalo se to certifikátů vystavených do 8 hodin od validace toho, že držíte doménové jméno, a i z těch vystavených později se to netýkalo těch, kde byla jen jedna doména. Využít to k záměrnému útoku by bylo obtížné (a útok by spočíval v tom „chtěli jsme vydávat certifikáty od LE, ale v posledních 30 dnech jsme si to rozmysleli, ale jen pro některé domény“). Možnost zneužití je podle mne prakticky nulová, ale je to prostě situace, kdy CA vydala certifikáty, u kterých není schopná garantovat, že byla oprávněná je vydat, tak je revokuje. Takže revokace je správná, trochu mne překvapila ta rychlost, kdy oznámení e-mailem šlo nějakých 8 hodin před okamžikem, kdy mohla začít revokace. (Proto jsem to také dával sem jako zprávičku – já jsem si toho e-mailu všiml jenom proto, že mne na něj GMail speciálně upozornil, že je to něco, čemu je potřeba se věnovat hned.) Chápal bych to v případě, kdy by šlo o reálnou možnost útoku. Na druhou stranu se tím nastavuje pravidlo, že se v takovýchhle případech bude postupovat rychle, což podle mne má něco do sebe.

Na druhou stranu, chtělo by to v rámci ACME i tyhle revokace ze strany CA nějak zautomatizovat – protože dnes je LE postavené na automatizaci, a tohle je najednou úplně jiný prvek, který vyžaduje, aby správce zareagoval na e-mail, vstoupil do toho automatizovaného procesu a ručně vynutil obnovu certifikátů. Jednak to někde může být problém – dovedu si představit, že je někde automatika nastavená na obnovu každý měsíc a nepočítá se s tím, že by to šlo snadno spustit ručně mimo termín. Druhá rovina je trochu filozofická – připadá mi trochu nesmyslné, že nějaký robot u LE posílá e-maily lidem, aby šťouchli do jiných robotů, že mají něco udělat. Ty role bych si představoval spíš opačně :-) Chápu, že je to něco úplně nového, dnes veškerou komunikaci zahajuje žadatel o certifikát – ale nějaký volitelný webhook, na který když LE sáhne, dá tím najevo, že by možná bylo vhodné daný certifikát obnovit, by byl užitečný.

To co pisete docela odpovida. Ty certifikaty, ktere jsem musel obnovovat byly vesmes takove kde se v posledni dobe menily domeny v jednom certfikatu. (Napr. pridani .eu varianty k jiz existujici .cz domene, a pod.)

K te automatizaci - bylo by fajn kdyby klienti (certbot, dehydrated), u platnych certifikatu overili jestli nejsou revokovane a pripadne je obnovili. Coz by pri dennim spousteni minimalizovalo vypadek, ale zase vyrazne zvysilo zatez servru LE.

Jenom jsem přebásnil a trochu rozvedl informace od LE. Doufám, že oni vědí, v čem byl problém…

Jinak pokud by se to mělo řešit dotazování, dává smysl spřáhnout to s OCSP stapling. Dokud mám na serveru platnou OCSP značku, kterou můžu přibalovat, revokace mne nemusí tolik zajímat. Jakmile při její obnově zjistím, že byl certifikát revokován, nechám vystavit nový (a pošlu upozornění adminovi).

To by bylo super, ale není to tak triviální implementovat. Server, který se dotazuje na OCSP, je typicky jiný kus softwaru než ten, který vyřizuje certifikáty. Dokonce certifikát může používat i více serverů – třeba mailserver a webserver. Jasně, šlo by implementovat nějaký hook, jen chci upozornit, že to není tak triviální, jak se může na první pohled zdát. Zvlášť pokud si různé kusy softwaru vymyslí různé mechanismy hooku.

> Na druhou stranu, chtělo by to v rámci ACME i tyhle revokace ze strany CA nějak zautomatizovat – protože dnes je LE postavené na automatizaci, a tohle je najednou úplně jiný prvek, který vyžaduje, aby správce zareagoval na e-mail, vstoupil do toho automatizovaného procesu a ručně vynutil obnovu certifikátů

To by se určitě hodilo, otázkou jsou náklady, spolehlivost a přínos.

Přínos by tu určitě byl, i když to není něco, co bychom řešili každý rok…

Náklady ovšem nejsou úplně zanedbatelné a dosáhnout dobré spolehlivosti taky není sranda. Máme spoustu klientů, kteří se integrují různými způsoby. Nezřídka ACME klient neposlouchá na žádném portu, takže bychom museli vymyslet komunikaci směrem k němu. Často tu nějaká možnost bude, ale můžeme vystavovat i certifikát na doménu, kde nemáme přístup k webserveru a kde se ověřujeme pomocí DNS záznamů.

Ve výsledku tak ne vždy máme zpětný komunikační kanál, a i pokud máme, často by ho musel admin nějak napojit na klienta. Pokud to nebude povinné, ne každý software to bude umět a ne každý správce to reálně nasadí. Přínos v této situaci by ovšem mohl vypadat i tak, že LE obnoví o pár stovek certifikátů víc a pár adminům ušetří práci. Pokud to bude povinné, mohlo by to omezit rozšiřování TLS. (Představte si tento argument před pěti lety, když LE začínalo…)

Užitečné by to tedy určitě bylo, ale:

1. Celkem chápu, proč se do toho v LE nepouštěli od dne 0.
2. Pochopím i teď, pokud dají přednost jiným vylepšením.

Jak se ukázalo, bez toho automatizovaného obnovení prakticky nejde certifikáty vydávané přes ACME hromadně revokovat. Resp. pokud to bude nutné, bude to hodně bolet. I proto, že to používají různé NASy, kde si domácí uživatel něco naklikal, zadal tam bůhvíjaký e-mail a i když mu přijde od CA e-mail, nerozumí v něm ani slovu. A také spousta webů, kde někdo rozchodil nějakého klienta, a dál se o to nestará a nerozumí tomu.

Já neříkám, žé to není žádný problém. Je to problém, který nemá snadné řešení a který za těch cca 5 let nastal poprvé. Co teď?

a. Pokusit se zavést podporu nějakých hooků, kterou je možné volitelně využít. To může na první pohled vypadat fajn, ale pokud to nasadí pár svědomitých adminů, je to v takové situaci minimální přínos. Tito admini by nejspíš byli z těch, kteří by certifikát stejně obnovili ručně, takže s ne až tak velkou nadsázkou by jediný přínos byl, že jednotky lidí takovou situaci nebudou muset řešit z dovolené.
b. Hooky, ale povinně. Možná by to dnes šlo bez nějakých velkých side effectů, ale nevím. Muselo by se to udělat dostatečně jednoduché. Taky je otázka, jak by se to mělo dotknout stávajících domén (změna za běhu vs. rozdílná pravidla).
c. Vymyslet nějaké jiné a lepší řešení.
d. Pokud plán C selže, vykašlat se na to. Jednoduše protože na stole možná není řešení, kde by náklady (včetně nákladů příležitosti) byly nižší než přínos.