Jak Heartbleed poukázal na slabiny certifikačních autorit

Nejspíše jste zaznamenali objevenou zranitelnost v OpenSSL nazvanou Heartbleed, která může vést nejen k odcizení privátních klíčů z SSL certifikátů. Pro odstranění tohoto problému je potřeba aktualizovat knihovnu OpenSSL a vyměnit klíče a certifikáty. Samotná aktualizace není dostatečná, neboť tato chyba byla v dotčené knihovně dva roky a není způsob jak zjistit, zda došlo k odcizení klíčů. Proto je nutno přistupovat ke všem serverům se zranitelnou knihovnou jako ke kompromitovaným.

První problém nastává s vystavením nových certifikátů. Původní plán byl nasadit na aktualizované servery nové certifikáty a po otestování revokovat certifikáty původní. Bohužel certifikační autorita (CA) je jiného názoru a bez revokace není možno vystavit certifikát nový. Smířili jsme se tedy s drobným výpadkem a požádali jsme o revokaci. Operace, která běžně trvá několik málo minut, trvala minulý týden díky stejnému postupu mnoha provozovatelů webů několik hodin. Navíc po půl hodině čekání jsme zjistili, že se žádost o revokaci certifikátu vyřizuje, ale systém autority nepřijímá nové žádosti, takže reálně hrozilo, že zůstaneme bez platného certifikátu. Po třech hodinách se akce zdařila a my se snažili nasadit nový certifikát co nejdříve, což byla další chyba. Certifikát ještě nebyl v seznamu pro OCSP, který slouží pro ověření platnosti certifikátů a vydává ho CA. Tudíž se nešlo na dotčené stránky připojit z Firefoxu. Výsledek ověření se ukládá na serveru CA do cache a vygenerování nového záznamu a jeho vypropagování trvalo dalších 8 hodin. Ve všech těchto krocích jsme byli plně závislí na CA, která byla logicky zahlcena a nestíhala jednotlivé požadavky vyřizovat.

Řešení této situace je přitom velmi snadné. Je jím samozřejmě DANE. V prvním náporu jsme si mohli vygenerovat vlastní certifikát a pomocí TLSA záznamů ho označit za správný a důvěryhodný a z bezpečnostních důvodů poslat požadavky na revokaci všech certifikátů. Stále bychom však měli validní a bezpečný certifikát na stránkách. Po opadnutí hlavního náporu bychom si mohli v klidu požádat o nový certifikát. Na druhou stranu, potřebovali bychom ho ještě? Nezbývá než doufat, že se tato šikovná funkce co nejdříve rozšíří. Do té doby můžete použít rozšíření pro prohlížeče.

Perlička na závěr. I když je u některých CA certifikát zdarma, jeho revokace je placená a může se tak stát, že na mnoha stránkách zůstanou kompromitované certifikáty.

Autor:

Komentáře (12)

  1. petr_p říká:

    Takhle tendenčně překroucený zápisek jsem už dlouho nečetl. A tady bych ho ani nečekal. Platnost certifikátu nerozhoduje nějaký bit v DNS, který vám může registrátor nebo správce zóny podvrhnout, ale certifikační politika vydávající autority.

    • Petr Černohouz říká:

      Nejde o platnost revokovaného nebo nově vydaného certifikátu. Měl jsem na mysli situaci, kdy si necháme revokovat starý certifikát a po přechodnou dobu do vydání nového bychom používali self-signed certifikát, který by však díky TLSA záznamu nezpůsoboval varování v prohlížeči. Samozřejmě podmínkou pro důvěřování TLSA je DNSSEC.

    • Ondřej Surý říká:

      A kterou certifikační autoritu přesně máte na mysli? Íránskou, tureckou, čínskou nebo americkou? Přesně tyhle tajné služby^U^Ucertifikační autority rozhodují o platnosti *validního* certifikátu.

      A tak raději flikujeme browsery natvrdo zakompilovanými hashi certifikátů a děláme jiné podobně divné věci… to je dnes totiž velmi tendenční…

  2. Ondřej Caletka říká:

    Docela mě zaujala odkazovaná diskuze na Twitteru, která se zvrhla v lynčování StartSSL za to, že odmítli odpustit poplatek 25 USD za revokaci certifikátu, který je vydán zadarmo.Je zvláštní, jak lidé při nabídnutém prstu okamžitě sahají po celé ruce.

    • Petr Černohouz říká:

      Tweet jsem odkázal hlavně kvůli tomu, abych upozornil na riziko, že kvůli nepřečtení podmínek při vystavování certifikátu mohou zůstat na netu potencinálně prolomené certifikáty.

    • Ondřej Surý říká:

      Osobně se domnívám (no_hat_on), že ve výjimečných případech by se i CA měly chovat výjimečně a poplatek odpustit. V případě DV certifikátů stejně akorát prodávají teplou vodu…

  3. Filip Jirsák říká:

    Pokud bude certifikát jak podepsaný CA, tak v DANE, mělo by platit, že platné musí být obojí, ne alespoň jeden. Podmínka AND bezpečnost zvýší (v případě útoku je potřeba napadnout oba kanály), podmínka OR ji sníží (stačí zaútočit na ten nejslabší kanál).

    Odmítnutí vystavení nového certifikátu před revokací starého se předpokládám týká jen situace, kdy jste chtěli nový certifikát vystavit zdarma jako náhradu toho revokovaného? Jinak k tomu přeci není žádný důvod a je legitimní mít více certifikátů na jedno jméno.

    Předpokládám, že jde ale jen o způsob nastavení procesů, do teď asi nikdo nepředpokládal, že by se certifikáty revokovaly preventivně, tj. potenciálně prozrazený certifikát ještě na serveru ponechám a revokuju ho až po výměně. Přitom CA to může vyřešit snadno, prostě si dá do pravidel, že při náhradě certifikátu ten starý automaticky revokuje třeba po 24 hodinách.

    Petr_p: pokud bude ten DNS záznam podepsán DNSSEC, jeho podvržení je stejně „snadné“, jako podvržení podpisu CA na certifikátu. Rozdíl je jenom v tom, že privátní klíč CA je lépe chráněný, než privátní klíč k běžné DNSSEC doméně.

  4. mishino říká:

    GoDaddy to ma bez problemov, stary certifikat sa revokne 72 hodin po vydani noveho.

    Proces vydania noveho certifikatu s novym csr trval par minut. Bez akychkolvek dalsich poplatkov.

  5. petr_p říká:

    Pro registrátora a správce zóny je podvržení záznamu triviální. Jako může změnit záznam TLSA, tak může vyměnit záznam DNSKEY a přegenerovat všechny RRSIG.

  6. petr_p říká:

    [Kterou certifikační autoritu přesně máte na mysli?] Tu, která vydala daný certifikát. Jak již bylo napsáno, řada autorit nemá problém vydat více certifikátů na stejné jméno (oprávněné osobě :) Stačí si před uzavřením vztahu nastudovat certifikační politiku a podle toho vybrat autoritu.

    Překroucenost spočívá v tom, že nevydaný certifikát řešíte self-signed certifikátem. Tím jste ale problém vůbec nevyřešili. Pouze vykřikujete, že když si uživatel do důvěryhodných autorit přidá ICANN a implementuje DANE, tak si bude moci nový certifikát ověřit. To už jste rovnou mohli změnit autoritu a nejistý požadavek na podporu DANE by odpadl. Navíc zmiňované pochybné autority mohou vydat falešný certifikát bez ohledu na to, že jste se rozhodli pravý certifikát vyměnit. Tohle je tendenční.

    Podle mě autentičnost DNS záznamů není tak dokonalá, jak ji prodáváte. Pokud si stěžujete na desítky kořenových certifikačních autorit, proč si nestěžujete na desítky registrátorů pod cz.? Naštěstí se lze oprávněně domnívat, že se záznamy pro jednu doménu může manipulovat jen její aktuální registrátor. (Otázka je, jestli to takto mají pojištěné všechny zóny.) Pak se problém důvěryhodnosti zmenšuje na délku cestu ve stromě DNS. V případě domény druhé úrovně to jsou tři entity. To je pravda proti desítkám autorit značný pokrok a v tomto smyslu lze hovořit o zlepšení.

    • Ondřej Surý říká:

      @petr_p: Ano, doménu může změnit jen její aktuální registrátor, a i proti těmto změnám se dá ochránit (nejen .CZ má registry level lock). U certifikátů stačí, aby jej vydala libovolná certifikační autorita, kterou máte v trust store.

      Použitím DANE nezměníte security model – už dnes si může registrátor (a/nebo správce zóny) nechat v klidu vystavit DV certifikát. Mluvil jsem o tom na různých místech již mnohokrát.

      Celé PKIX a šaráda okolo CA je největší security fail v historii.

    • Filip Jirsák říká:

      PKIX a CA neřeší jen doménová jména. Identitu osob asi přes DANE neověříte…

Zanechte komentář