Hlavní navigace

Vlákno názorů ke zprávičce Let's Encrypt zítra revokuje 3 miliony certifikátů od Vojtěch Myslivec - Vypozoroval nekdo presny vzorec, za jakych podminek LE...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 4. 3. 2020 0:57

    Vojtěch Myslivec

    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.

  • 4. 3. 2020 11:37

    Vojtěch Myslivec

    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

  • 4. 3. 2020 16:34

    Filip Jirsák

    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).

  • 4. 3. 2020 7:14

    BobTheBuilder

    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.

  • 4. 3. 2020 10:20

    Ondřej Caletka

    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.

  • 4. 3. 2020 11:41

    Vojtěch Myslivec

    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.

  • 5. 3. 2020 11:16

    bez přezdívky

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

  • 5. 3. 2020 22:26

    Ondřej Caletka

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

  • 4. 3. 2020 17:11

    Filip Jirsák

    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.

  • 4. 3. 2020 16:32

    Filip Jirsák

    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ý.

  • 4. 3. 2020 17:32

    Vladki

    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.

  • 4. 3. 2020 20:25

    Filip Jirsák

    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).

  • 7. 3. 2020 11:24

    Vít Šesták

    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.

  • 7. 3. 2020 12:39

    Vít Šesták

    > 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.

  • 9. 3. 2020 23:03

    Filip Jirsák

    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.

  • 9. 3. 2020 23:52

    Vít Šesták

    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.

  • 10. 3. 2020 9:11

    Filip Jirsák

    Ano, nastal teď poprvé, ale bylo by naivní domnívat se, že už se nic takového nebude opakovat. Navíc protokol ACME má ambice stát se univerzálním protokolem pro vystavování certifikátů, a čím víc se to bude automatizovat (což je správné), tím větší potřeba bude řešit i tenhle krok. Protože čím větší automatizace, tím větší problém do toho pak zasáhnout ručně.

    Povinné hooky jsou nereálné, nejsou páky, jak k použití někoho donutit. Dalo by se udělat to, že by se třeba vystavení certifikátu změnilo na hook – když už by někdo implementoval hook pro získání certifikátu, spíš by implementoval i ten pro vynucení obnovy. Ale to je nereálné. Mně by ale nijak nevadilo ani to, že by podpora hooků byla zcela volitelná. Problém totiž vidím v tom, že dnes to nikdo vyřešit nemůže, i kdyby chtěl.

    Znovu uvedu jako příklad NAS servery – že používají certifikáty je správně. Že to zcela automatizují a funguje to bez zásahu uživatele, to je také správně. Výrobci NASů tedy dělají vše správně (pokud teda nemají to omezení, že je možné certifikát obnovit nejdříve 10 dnů před koncem platnosti), přesto může nastat situace, že statisíce uživatelů budou mít kvůli revokovanému certifikátu nedostupný NAS – přitom chybu neudělá ani uživatel ani výrobce NASu. Takže mi jde jen o to dát tomu, kdo to chce řešit, do rukou nástroj, kterým to bude moci vyřešit. Ono by možná stačilo jen standardizovat e-mail – umožnit uvést pro tyhle případy druhý e-mail, který by si výrobce NASů přesměroval na sebe a zapojil ho do vzdálené správy NASu, a ten e-mail by měl nějakou standardizovanou strojově čitelnou přílohu (asi JSON, když jsme v ACME protokolu).

    Neříkám, že je to snadné. Ale před několika lety bylo nepředstavitelné mít protokol pro automatizované vydávání certifikátů. Také tam byly potřeba hooky – majitel domény musí být na výzvu schopen prokázat, že doménu ovládá. A podařilo se to vyřešit.