Vydán podvržený certifikát pro *.google.com

Bezpečnostní blog Mozilly informuje, že došlo k revokaci falešného certifikátu domény Googlu. Tento certifikát byl úspěšně použit k útokům v Íránu. K jeho vydání došlu již 10. července. Více viz rozbor EFF.

30.8.2011 20:37 | Nicky726 | Bezpečnostní upozornění

Komentáře

[David Jaša]

Můžu si už dát certifikát od Comodo opět do důvěryhodných, nebo jejich reselleři furt vystavují certifikáty pro MITM útočníky?

[Andrej]

Stačila by jednoduchá konvence spočívající v získávání otisků certifikátů z DNSSEC. Zkrátka by se přidal další typ záznamu, podobně jako v případě DKIM nebo dalších bezpečnostních mechanismů. DNS server by tedy poskytoval také informace o otiscích veřejných klíčů pro každou dvojici (stroj, protokol), kterou vede v patrnosti, pokud daná dvojice používá TLS.

Mezi poskytovateli připojení k Internetu jsou však bohužel stále ještě tupci, kteří o DNSSEC nejspíš neslyšeli. To je dost zásadní překážka v nasazení této technologie. Jednoduché rozšíření getaddrinfo() o podporu popsané funkcionality si ovšem umím snadno představit.

Každá klientská aplikace by díky tomu měla velmi silný prostředek k ověřování pravosti certifikátů, nesrovnatelně rychlejší a spolehlivější než všechny mechanismy založené na CRL.

[Foo Bar]

DANE WG@IETF, viz také můj článek Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF.

S tím gai() to taky nebude tak jednoduché, potřebujete zabezpečit celý "Last Hop", ale také se na tom pomalu ale jistě pracuje.

[Andrej]

Pravda, když nebudu mít zabezpečený last hop a budu slepě poslouchat AD, je jakékoliv úsilí marné. Ani bezpečný last hop nepomáhá, protože za ním se může skrývat nedůvěryhodný cizí stroj (u drtivé většiny domácností standardní situace). To je mrzuté. To aby měl rovnou každý prohlížeč v sobě svůj vlastní DNS resolver a hardcoded klíč kořenové zóny.

Nicméně stále tu vidím ještě jedno možné řešení: Do getaddrinfo() by mohl přibýt další flag, který by nařídil do odpovědi vložit celý chain of trust (na konci rozvětvený...), který vedl k získání vrácené IP adresy a otisku certifikátu pro TLS. Díky tomu by pak

• nemusel být zabezpečený last hop.
• nemusel být DNS server lokální a důvěryhodný.
• stačilo mít v klientovi používajícím TLS napevno pouze certifikát kořenové zóny DNS.

Takový chain of trust by sice mohl narůst do velkých rozměrů, ale last hop je rychlý, že ano. (Zbytek vyřeší cache.) Podvržení certifikátu tento mechanismus odhalí snadno. Horší je to ovšem s vyzrazením soukromého klíče. Tam by až do vypršení TTL stále hrozilo nebezpečí. Nicméně pořád to může být kratší doba ohrožení než extrémní třicetidenní platnost některých CRL. Navíc by tady (v ostrém kontrastu se soustavně ignorovanými, ne-li těžko dostupnými CRL) certifikát někdo konečně opravdu ověřoval.

[Foo Bar]

Ani bezpečný last hop nepomáhá, protože za ním se může skrývat nedůvěryhodný cizí stroj (u drtivé většiny domácností standardní situace).

Tím Last Hopem jsem myslel i tu důvěru v používaný resolver viz moje prezentace Securing Last Hop na posledním IETF.

To aby měl rovnou každý prohlížeč v sobě svůj vlastní DNS resolver a hardcoded klíč kořenové zóny.

Tak to pravděpodobně ze začátku dopadne. Případně to nemusíte cpát do prohlížeče, ale stačí malinký validující stub resolver na localhostu, pokud byste si s něčím takovým chtěl pohrát, tak jsem udělal takový malý mashup evldns a libunbound, kterému pracovně říkám stubound:

# git clone git://git.nic.cz/evldns-stubound

odpovědi vložit celý chain of trust (na konci rozvětvený...)

Adam Langley (@Google Chrome) navrhuje DNSSEC "razítkovat" X.509 certifikáty, viz prezentace DNSSEC serialization na tomtéž a jeho poslední blogpost.

Nesmíte zapomínat, že gai() je POSIX, takže tohle rozhraní nemůžete měnit jen tak hopsa hejsa. Spíš to dopadne tak, že vznikne nějaká obecná knihovna s dohodnutým rozhraním (podobně jako OpenSSL), která bude takové rozhraní poskytovat, a časem do toho POSIXu doputuje.

Tam by až do vypršení TTL stále hrozilo nebezpečí. Nicméně pořád to může být kratší doba ohrožení než extrémní třicetidenní platnost některých CRL. Navíc by tady (v ostrém kontrastu se soustavně ignorovanými, ne-li těžko dostupnými CRL) certifikát někdo konečně opravdu ověřoval.

Souhlasím na 100%. Proto na tom pracujem, jak rychle to IETF dovoluje... (což není zrovna warp speed, ale dopředu se to hýbe docela svižně).

[pavlix]

Tím Last Hopem jsem myslel i tu důvěru v používaný resolver viz moje prezentace Securing Last Hop na posledním IETF.

Nevidím důvod, proč to, mimo corporate prostředí, řešit jakkoli jinak než lokálním resolverem přímo v systému.

[pavlix]

Ještě k DNSSEC+TLS...

Já jsem ten kverulant, který při IT11 na jabberu kritizoval důvěru v jakési root CA kdesi, čímž jsem si určitě u vás nevysloužil dobrou pověst :), ale paranoia je paranoia.

Řekněme, že přechod od důvěry „každý každému“ (současná metoda, kdy každá CA může tvrdit cokoli), ke „stromu důvěry“ (kdy root rozděluje na TLD, a tak dále), je takový malý krok k lepšímu zabezpečení (podle některých finální řešení, ale s tím se rozhodně nespokojím).

Samozřejmě, že bezpečnost využívá centralizovaných i decentralizovaných metod... kdy centralizované se ukazují jako dobré pro přísně hierarchické organizace bez nějakých vnitřních problémů. Pro celosvětové nasazení může centralizace znamenat možnost sesypání systému jako celku.

Takže by bylo fajn, kdyby lidi, kteří se podílejí na podobných věcech jako je DNSSEC a TLS brali do budoucna v úvahu i následující případy:

1) Mám systém, ve kterém chci využívat TLD nezávislou na DNS root a přitom chci používat stejnou bezpečnostní infrastrukturu (hloupý, ale notoricky známý případ *.czf, jistě najdete lepší případy).

2) Nechci být při vnitrofiremní komunikaci nijak závislý na autoritách vnějšího světa. Tzn, jsem v infrastruktuře .example.com a chci komunikovat s .example.net. Tzn, .example.net se bude vždy ověřovat pomocí ručně zadaného certifikátu, a nikdy pomocí globálního DNS certifikátu.

Přijde mi, že tohle jsou naprosto základní požadavky robustní infrastruktury, která nemá při prvním průšvihu lehnout popelem celá.

[Foo Bar]

Ani 1) ani 2) se nevylučuje s lokální konfigurací resolveru.

Ad 1) přidáte TA pro .czf, tj. je to vaše lokální politika akceptovat i klíč pro .czf

Ad 2) to jak vaše počítače vidí ostatní domény a pomocí kterých klíčů validují informace z DNS je opět vaše lokální politika

[pavlix]

Ad 1) přidáte TA pro .czf, tj. je to vaše lokální politika akceptovat i klíč pro .czf

Což je podstatně odlišné od požadavku (1).

Ad 2) to jak vaše počítače vidí ostatní domény a pomocí kterých klíčů validují informace z DNS je opět vaše lokální politika

A přesně o tom mluvím, aby se s takovou lokální politikou počítalo. Součástní dobrých standardů přece není jen hrubý popis vnějších protokolů.

[Foo Bar]

No, já myslím, že úplně stačí, že navrhované standardy nekecají do lokální politiky. To, jak divně si nakonfigurujete vlastní síť, je čistě vaše věc. Standard by vám v tom akorát neměl (moc) bránit.

[pavlix]

To, jak divně si nakonfigurujete vlastní síť, je čistě vaše věc.

No moment… jestli základní požadavky na zabezpečení komunikace (tedy integritu a vzájemnou autentizaci) bude vyžadovat konfiguraci, kterou vy nazýváte „divná“, tak doufám, že se nad těmito požadavky zamyslí alespoň někdo jiný.

[Foo Bar]

Podsouváte mi do úst něco, co jsem neřekl.

[pavlix]

Jistě ne úmyslně.

Rád bych tedy našel ten bod, ve kterém jsem vás špatně pochopil, a ze kterého jsem vyvodil to, co jsem napsal.

Osobně jsem vás pochopil tak, že konfiguraci, kdy se nespoléhá ve všem na root certifikáty (tedy například když určitý podstrom vyjmu a přiřadím mu jiný kořenový certifikát), považujete za divnou konfiguraci. Já považuju za průkazné, že root certifikáty (operované třetí stranou) nezajišťují přímou (dvoustrannou) vzájemnou autentizaci, ale nepřímou (za důvěry třetí straně).

Tzn systém, který plně spoléhá na jeden DNS kořen má sice méně zranitelných míst, než systém, kde každá autorita certifikuje cokoli, nicméně to zranitelné místo je stále fatální, a takový systém nesplňuje požadavek na přímou vzájemnou autentizaci (která je ve specifických případech na místě).

Někde musím mít chybu.

[Foo Bar]

Když nahradíte slovo 'divnou' za 'nestandardní', tak už to do vašeho modelu světa bude pasovat lépe?

Pro mě je 'nestandardní' ~= 'divná', měl jsem za to, že tady volně diskutujeme a netvoříme RFC.

[pavlix]

Takže mám pocit, že moje narážka šla správným směrem. Považuju za velkou slabinu kombinace DNSSEC a TLS, pokud se bude všeobecně konfigurace certifikátů pro jednotlivé podstromy považovat za „nestandardní“.

Ale tak jako tam tomu fandím. Lepší vrabec v hrsti, než holub na střeše.

[Foo Bar]

Já vám asi opravdu nerozumím, o co vám jde. Pokud nepoužíváte standardní DNS strom, tak máte v DNS minimálně kus nestandardního stromu. A je to na vás, abyste si to nakonfiguroval tak, aby vám to fungovalo dobře. Nikdo vám v tom bránit nebude. Pokud zajistíte, že se informace o TLSA záznamu z DNS vrátí jako DNSSEC-validní, tak z hlediska standardu to bude v pořádku.

Stejně tak, pokud se v Elbonii rozhodnout, že nebudou používat ICANN kořenové servery, ale budou mít vlastní s jiným podpisem a všem elbonijským ISP nakážou, že to bude tak a ne jinak, tak to tak budou mít.

Nicméně nemůžete čekat od RFC, že v sobě bude obsahovat i popis konfigurace DNS v Elbonii.

P.S.: Taky nerozumím tomu, co si představujete pod "všeobecně konfigurace certifikátů pro jednotlivé podstromy". Možná bych navrhoval ke čtení DANE use cases a DANE protocol, abychom se bavili o tom samém.

[pavlix]

Já vám asi opravdu nerozumím, o co vám jde.

Jen a jen o to, aby standardní implementace umožňovaly přímo svázat kteroukoli subdoménu (podstrom) s konkrétními kryptografickými klíči, tak jako je celý strom svázán s těmi globálními.

Tedy abych mohl tomu podstromu dát vyšší úroveň zabezpečení, než je ta přes třetí stranu, a přitom pro celý podstrom šly dále používat stejné, už jednou vymyšlené, mechanismy.

Teď si začínám uvědomovat, že by to možná stačilo řešit v samotném DNSSECu, protože už ten je pro daný podstrom v rukou provozovatele domény.

Prostě a jednoduše, pro konkrétní vztahy mezi subjekty zkrátit řetěz důvěry tak, aby neobsahoval třetí stranu (bez ohledu to, kdo tou třetí stranou je).

Mně to připadá srozumitelné (tedy alespoň v té podobě, v jaké jsem to teď napsal).

Pokud nepoužíváte standardní DNS strom, tak máte v DNS minimálně kus nestandardního stromu. A je to na vás, abyste si to nakonfiguroval tak, aby vám to fungovalo dobře. Nikdo vám v tom bránit nebude. Pokud zajistíte, že se informace o TLSA záznamu z DNS vrátí jako DNSSEC-validní, tak z hlediska standardu to bude v pořádku.

Proto jsem ty dva body očísloval, aby se nepletly dohromady, například bod 2 žádné nestandardní TLD nezahrnuje.

Stejně tak, pokud se v Elbonii rozhodnout, že nebudou používat ICANN kořenové servery, ale budou mít vlastní s jiným podpisem a všem elbonijským ISP nakážou, že to bude tak a ne jinak, tak to tak budou mít.

O tom jsem myslím nikde nepsal.

Nicméně nemůžete čekat od RFC, že v sobě bude obsahovat i popis konfigurace DNS v Elbonii.

O tom jsem myslím také nikde nepsal.

P.S.: Taky nerozumím tomu, co si představujete pod "všeobecně konfigurace certifikátů pro jednotlivé podstromy". Možná bych navrhoval ke čtení DANE use cases a DANE protocol, abychom se bavili o tom samém.

Tak předpokládám, že šifrovaná komunikace mezi dvěma subjekty pod usecases spadá (nevím, o čem jiném by ten stanard byl). Zbytek viz výše. Našel jsem čas na prolétnutí obou protokolů, ale spíš tam vidím hromadu technických detailů, jak to tak bývá, a ani v introduction nevidím nic, co by se týkalo toho, co píšu.

[polymorf]

Nastroje->Moznosti->Spresnenie->Sifrovanie->Certifikaty->Autority

Najst DigiNotar a odstranit. Inak je tam plno takych o akych som v zivote nepocul (max. tak VeriSign, Thawte a par dalsich), takze som si ich vsetky vymazal.

[SPM]

Což pořád neříká nic o tom, že jedna z těch, co jste nechal, křížově podepíše jinou, ta jiná vydá certifikát s právy CA nějakému pepovi někde a už jsme zase tam, kde jsme...

[polymorf]

Ano, ale taketo preslapy zatial urobili len male CA

[Mrkva]

... přešlapy o kterých víme zatial...

[SPM]

Nj, jenže ty důvěřuješ celému řetězci - ne jen tomu, co je podepsané klíčem, jehož certifikát máš v browseru... tzn. nikdy nevíš, jestli některá z těch velkých CA, co tam máš, nedůvěřuje nějaké malé a tudíž ta validace projde

[Filip Jirsák]

Myslíte, že by ta velká CA automaticky podepisovala certifikáty vydané tou malou CA? K čemu by to bylo dobré? Navíc i takto vydané certifikáty by stejně musely splňovat certifikační politiku té velké CA – a pokud ji nějaký certifikát nesplňuje, je mi jako uživateli jedno, jakým interním mechanismem k tomu u CA došlo.

[SPM]

No po diskuzi s (ne)hashovanými hesly na abíčku s vámi můžu tak akorát říct, že jako uživatel nemáte šanci do žádných procesů CA zasahovat, tudíž je všechny musíte považovat za nedůvěryhodné, protože nemůžete věřit tomu, že na té cestě ke stromu se nedostane nějaká nespolehlivá všepodepisující CA.

[Filip Jirsák]

Cesta od (listového) certifikátu ke kořenovému certifikátu CA není nic neznámého tajemného. V okamžiku ověřování musíte mít kořenový certifikát i všechny mezilehlé certifikáty k dispozici (ať už z vlastního úložiště, nebo jste je získal spolu s certifikátem, který chcete ověřit), takže se stačí podívat, co je to zač. Navíc každý rozumný certifikát CA má nastavenou maximální hloubku stromu (typicky se buď koncové certifikáty podepisují buď přímo kořenovým certifikátem, nebo je tam jeden mezilehlý certifikát). Zároveň CA při podpisu certifikátu nastaví správně příznak, zda ten certifikát může podepisovat jiné certifikáty – a ten příznak dají jen několika málo mezilehlým certifikátům.

[SPM]

Což stále nic nemění na faktu, že certifikáty velkých autorit, které mám naimportované, můžou vydat další certifikát pro další certifikační autoritu a ta klidně už může dělat nějaké nekalosti... a tvrzení, že ty velké autority to jentak někomu nepodepíší mě asi moc neuklidní - prostě nějaká chyba může nastat zase v úplně jiném subjektu, kterému nějakou cestou důvěřuje ta velká CA, kterou mám v browseru

[Filip Jirsák]

Četl jste, co jsem napsal? V certifikační politice certifikační autority se dočtete, jestli může podepsat certifikát jiné autoritě – a pokud ano, bude nejspíš klást na její certifikační politiku takové nároky, jaké má ona sama. Tolik k právnímu hledisku. technicky vám nic nebrání z úložiště certifikátů vyházet případné kořenové certifikáty a nechat tam těch pár, kterými ty „velké“ (lépe důvěryhodné) autority přímo podepisují certifikáty webů. Ty mají nastaveno, že v certifikační cestě pod nimi může být už jen jeden certifikát. Takže i kdyby takovým certifikátem CA podepsala certifikát jiné CA, internetový prohlížeč který certifikáty ověřuje správně by certifikáty podepsané tou „další CA“ nepovažoval za ověřené.

[SPM]

Ano, jenže papír snese všechno a to co je napsáno v certifikační politice nemusí odpovídat skutečnosti - koneckonců hádám, že i tyhle dnes už nedůvěryhodné CA měli certifikační politiku napsanou tak, která takovéhle zneužití popírala... ano - ta druhá část příspěvku ten problém řeší, ikdyž bude IMHO trochu pracnější - tipnul bych si, že v defaultu v tom prohlížeči budou ty úplně hlavní certifikáty, které bude potřeba smazat a najít jenom ty předposlední a těma je nahradit...

[Filip Jirsák]

Když nějaké politice CA nevěříte, neinstalujte jejich certifikát. Jak prosté. Pokud spoléháte na to, co máte jako výchozí v prohlížeči, je zbytečné se bavit o důvěryhodnosti certifikátů a certifikačních politik, protože stejně věříte certifikátům, které jste získal bůhví odkud.

[pavlix]

Přesně tak, nemá smysl dělat rozdíl mezi malými a velkými, ale mezi důvěryhodnými a nedůvěryhodnými.

[polymorf]

Zatial tam mam 3. To je oproti povodnym 50 (okrem inych aj turecke, cinske, ...) podstatne zlepsenie.

[pavlix]

Jenže to zlepšení by bylo potřeba udělat globálně.

[SPM]

Nj, ale spousta jsou důvěryhodné a důvěru ztrácí až s prvním průserem, co se provalí :)

[Foo Bar]

Comodo je malá CA?

[polymorf]

Az do toho pruseru som o nich nepocul, ani som nikde ziaden ich certifikat nevidel. Naproti tomu VeriSign a Thawte vidim na kazdom druhom webe. Takze ano, comodo je mala CA.

[Foo Bar]

Příloha:

• Screen Shot 2011-08-31 at 13.33.32.png (112147 bytů)

Myslím, že velikost CA se nepočítá podle toho, zdali jste o nich slyšel nebo neslyšel...

Přiložený graf je vykousnutý z prezentace EFF SSL Observatory.

[Heron]

Verisign je malá CA?

[Heron]

Verisign už měl v minulosti také pěkný problém. Vydal certifikát *.microsoft.com a dotyčný s tím potom podepisoval SW, který byl Windows bez řečí přijat.

Žádné CA nelze věřit. Každý certifikát je nutné ověřivat.

[Andrej]

Pekna ficura ten pubkey pinning:

This latest attack was reportedly caught by a user running the Google Chrome browser in Iran who noticed a warning produced by the “public key pinning” feature which Google introduced in May of this year. Basically, Google hard-coded the fingerprints for its own sites’ encryption keys into Chrome, and told the browser to simply ignore contrary information from certificate authorities.

Dalsim logickym krokom v Irane bude zakazanie pouzitia Google Chrome.

[Martin Hruska]

Takže to byla zřejmě vládní aktivita? Tomu se těžko odolává.

Stuxnet byl například podepsaný VeriSignem, který tu ostatní vyzdvihují jako neomylného.

[Filip Jirsák]

Pokud vím, Stuxnet nebyl podepsaný VeriSignem, ale ukradenými certifikáty firem. To, že ty ukradené certifikáty byly shodou okolností vydány VeriSignem s tím nijak nesouvisí – problém byl výhradně na straně těch firem, nikoli VeriSignu.

[Foo Bar]

Takže to byla zřejmě vládní aktivita? Tomu se těžko odolává.

To si myslím, že je dost divoká spekulace...