Nějak tu nevidím zmínku o Certificate Patrol – to doplněk do prohlížeče přesně pro tyhle případy – při změně certifikátu zobrazí varování – a to i v případě, že jde o certifikát od jiné „důvěryhodné“ CA. Psali jsme o něm tady: Doplňky pro bezpečnější prohlížení webu.
Certifikáty v DNS nejsou žádná spása, trochu pomůžou (je potřeba prolamovat dvě věci místo jedné), ale spoléhat se na ně nedá (a když se na ně spolu s DNSSEC spoléhat budeme, tak jsme zase u toho, že bezmezně věříme jedné autoritě). Pavučina důvěry je už zajímavější koncept, ale implementace zatím trochu pokulhává.
Té jedné autoritě (DNS) už věříte dnes a budete ji muset důvěřovat i v budoucnu. Pokud někdo ovládne vaše DNS, tak si jednoduše zvládne nechat vystavit i certifikát, aniž byste si toho měl šanci nějak pořádně všimnout.
Naopak... pokud ubyde aktérů, kterým implicitně důvěřujete, tak se celková důvěryhodnost systému zvýší.
Jinak TLSA záznam bez DNSSECu moc nedává smysl (resp. v restriktivním režimu - tj. říkám "tohle je můj certifikát a žádný jiný" se bez DNSSECu věci nezhorší - v otevřeném režimu je pak DNSSEC nutný, aby situaci útočníkovi nezjednodušil). Nicméně to je debata, která patří do mailinglistu DANE WG (a nejlépe po přečtení současného draftu) než do diskuze na root.cz.
Web of Trust bez ověřování důvěry offline kanálem umře buď na to, že si zlí hoši budou umět vybudovat "důvěryhodnější" WoT nebo na tom, že bude muset být někdo důvěryhodnější než ostatní (aka certifikační autorita), a s ověřování offline kanálem to zákonitě zanikne pro celkovou složitost. WoT je dobré pro osobní PGP, ale pro ověřování serverových certifikátů podle mě nic moc.
Ad „Té jedné autoritě (DNS) už věříte dnes a budete ji muset důvěřovat i v budoucnu. Pokud někdo ovládne vaše DNS, tak si jednoduše zvládne nechat vystavit i certifikát, aniž byste si toho měl šanci nějak pořádně všimnout.“
Jenže CA se nespoléhají jen na DNS (např. odeslání kontrolního mailu), navíc by bylo potřeba ovládnout DNS servery jak před obětí (uživatelem), tak před CA.
A odeslání kontrolního emailu nespoléhá na DNS?
Ano, stačí ovládnout uživatelovo DNS (nemluvím o spoofingu). Tj. situace je úplně stejná s TLSA nebo bez něj.
Jinak abychom si rozuměli, tak mluvím o DV (domain validated) certifikátech a nikoli o EV, kde se jedná o ověření identity subjektu (jinými slovy o to, co by CA měly dělat standarndně a nikoli za to vybírat peníze navíc).
Ad „A odeslání kontrolního emailu nespoléhá na DNS?“
To jsme si nerozuměli – jasně že kontrolní e-mail stojí na DNS, ale právě že CA se nespoléhají jen na ten kontrolní e-mail – je potřeba dodat ofocené dokumenty, být na příjmu na pevné lince, o které jim člověk pošle účet za poslední měsíc atd. u EV toho chtějí samozřejmě ještě víc.
No a v tom se právě pletete. Minimálně jedna (což je postačující podmínka) CA vám vystaví certifikát zdarma jen tak na základě toho, že máte email a nějaká data ve whoisu. Zkuste třeba startssl.com[1]. Thawte si s vámi u nejnižší úrovně certu taky jenom mailuje. S ostatními nemám zkušenost, ale je to jedno. Stačí jedna taková certifikační autorita, kterou máte mezi důvěryhodnými.
1. Příklad certifikátu, který jsem si zadarmo u nich vygeneroval bez jakéhokoli papírování: https://www.sury.org/
StartSSL taky používám – jenže on je rozdíl mezi Class 2 (StartCom Verified Certificate Member) a Class 1 (StartCom Free Certificate Member). U Class 2 toho ověřují právě trochu víc než jen ten e-mail.
Ono je celkem jedno, jaký je rozdíl mezi čím, důležité je, že drtivá většina lidí bude mít jako důvěryhodnou přímo jejich root CA a rozdíl mezi Class 1 a 2 samozřejmě u každé stránky zkoumat nebudu...
Btw, právě jsem si vyzkoušel, že Chrome se na MacOS chová dost podivně: když označím certifikát jako že už mu nedůvěřuju a potom znovu jdu na stránku, kterou jsem navštívil, dokud jsem mu důvěřoval, tak ta stránka zůstane "zelená" i když používá CA, které už nedůvěřuju.
Dost bída teda... :(
Záleží na konkrétním prohlížeči – např. takhle to vypadá v Epiphany – bezplatný vs. placený (resp. lépe ověřovaný) certifikát. Tohle je prostě chyba Firefoxu (případně jiných prohlížečů), podle mého by tam ten certifikát neměl být – ne proto, že je zadarmo, ale kvůli nedostatečnému ověřování (jinak nic proti bezplatným certifikátům, sám jsem o nich psal návod). Takový CACert tam např. taky není (u něj taky stačí ověření e-mailem). Tohle si musí vyřešit prohlížeče – ten zbytek je na delší diskusi.
O kousek lepší by bylo ověřování pomocí TXT DNS záznamu. To sice taky stojí na DNS jako to posílání kontrolních mailů, ale možnost nastavovat DNS záznamy znamená přeci jen něco víc – ten e-mail stačí jen odposlechnout cestou, ani není potřeba útočit na DNS. Navíc ten TXT záznam si může CA zkontrolovat z několika různých míst, nebo třeba požadovat, aby tam vydržel aspoň týden a pak teprve certifikát vydat – takže se dá útok téměř vyloučit.
Ad. Web of Trust: já bych spíš měl na mysli něco mírně jiného, než co se pod tím termínem rozumí v PGP případě - mít vícero hierarchií, např:
- Perspectives Servers, SSL Observatory (Perspectives postupně přepisuju na podporu SHA-1, aby to šlo integrovat s Observatory, plus další změny)
- Google přístup kde googlí crawler háže fingerprinty certifikátů do TXT záznamů v certs.googlednstest.com (ale dokud to nebude podepsáno třeba přes DNSSEC, tak to není moc velká výhra)
Cílem je mít z toho "out-of-band" mechanizmus (kromě klasického PKI, DANE nebo CAA), který by uměl rozlišit, zda je změna certifikátu "podezřelá". Perspectives/Certificate Patrol má momentálně "drobný problém" se servery, které "točí certifikáty často", např. encrypted.google.com nebo online.citibank.com:
(právě pro tyhle případy by se hodilo DANE nebo CAA jako vedlejší způsob zjištění policy organizace, jinak by člověk musel vytvářet výjimky ručně)
Neplánuje CZNIC v blízké budoucnosti otevřít další pozici na "security researcher"?
(tu poslední minulý rok jsem minul asi o den, na dva maily nikdo neodpověděl nic, ani "litujeme, je už obsazena"; obsazení jsem odvodil z toho, že inzerát byl rychle stažen)
Totiž dělat tohle vedle "regulérní práce" je časově nestíhatelné, člověk ani nestihne přečíst podstatné mailinglisty a nové drafty pořádně.