Vlákno názorů k článku Symantec chyboval s EV certifikáty, prohlížeče jim přestanou důvěřovat od Jose - Takže se konečně dospívá k pochopení že současná...

Google do toho netahej. Zjisti si, jak to bude fungovat a pak piš...

Prosim te: venuj cas tomu, ze se podivas na to, co kritizujes. Podivej se na to, jak funguji zakladni datove struktury. Zjisti si, jak funguji zakladni pravidla spolecenskeho chovani.

Akorát u SMTP a IMAPU asi žádné HKPK nemají. Taky mi můj poštovní klient řve, že google co dva dny mění certifikát. (Možná jde jen o nějakou formu loadbalancingu, nezkoumal jsem to.)

Taky mi můj poštovní klient řve, že google co dva dny mění certifikát.
Což ničemu nevadí, protože ve světě PKI se důvěřuje certifikační autoritě, ne veřejnému klíči. Takže je v pořádku, pokud dostanete jiný certifikát třeba při každém spojení – dokud bude od důvěryhodné certifikační autority.

Jenže současná implementace PKI je rozbitá. Já nemám na to, každé dva dny ověřovat, jestli je vydaný správnou CA. A nemám na to, každému programu vybírat jeho sadu CA, kterým věřím. Dokonce nemám ani na to sledovat stav CA a udržovat si povědomí o tom, která je důvěryhodná. Jak vidíme, tak máme v úložištích kořenových autorit spoustu CA s pochybnou důvěrou. Já tomu naštěstí svěřuji pouze firemní mejly (protože to tak dělá i zbytek firmy), ale kdyby mě někdo unesl ve firmě nebo v kavárně DNS, podstrčil mi špatný imap.google.com, i s certifikátem, tak se nic nedozvím, takže přinejmenším mne to nechrání proti MITM útoku. Prostě to vnímám jako reálnou hrozbu a spíš než jestli se ptám kdy.
Neřeším to jen proto, že je velmi nízká pravděpodobnost, že by takový útok byl cílen přímo na mne. Pokud by to postihlo celou firmu, tak bude celkem jedno, že zrovna mne nehackli. Pokud by to postihlo všechny návštěvníky kavárny, tak by pravděpodobně nehledal v mých mejlech jak zaůtočit zrovna na firmu ve které pracuji. Ostatně citlivé informace beztak šifruji.
Ale i tak to vnímám jako problém.

Neřekl bych, že je rozbitá celá implementace PKI, pouze její část – to, že v nejpoužívanějších předinstalovaných sadách „důvěryhodných“ certifikačních autorit je kde co a koncový uživatel se nemůže úplně spolehnout na to, že je tam výběr, kterému lze skutečně důvěřovat. (Na druhou stranu, kdyby se ten výběr nechal na koncových uživatelích, bude to v průměru ještě mnohem horší.)
Jenže řešením není ověřovat každý jednotlivý certifikát, jak tady neustále prosazuje Jéčko a ostatní.Když nemáte na to ověřovat certifikáty CA, už vůbec nemáte na ověřování jednotlivých certifikátů.
Řešením je rozdělit důvěryhodné seznam CA na balíčky důvěryhodných CA tak, aby si každý mohl vybrat, kterým balíčkům bude důvěřovat. A pro ověřování doménových jmen se spolehnout na DNS, stejně v tom musíme věřit registrátorům. Já bych si pak klidně vybral jako důvěryhodný jenom balíček autorit ověřujících podle eIDASu, protože u takových autorit vím, co od nich můžu čekat.

ROFL. https://en.wikipedia.org/wiki/DigiNotar
Na vašem místě bych se tak nesmál, protože máte rozbitý kalendář. DigiNotar zkrachoval v září 2011. eIDAS byl publikován v červenci 2014 a vstoupil v platnost v červenci 2016. DigiNotar tedy evidentně nikdy nemohl fungovat podle eIDASu, protože v té době ještě žádný eIDAS nebyl.

Rozdíl je v tom, že v případě autority máš alespoň nějakou jistotu, že proběhlo ověření. U nedůvěryhodného certifikátu (což nemusí být nutně pouze selfsigned) a u HTTP nemáš jistotu vůbec žádnou.
Omyl. V případě autority máš šanci, že tam mohlo dojít k řádnému ověření. Ale třeba taky ne.
U self-signed certifikátu máš JISTOTU, že nedošlo k žádnému standardnímu ověření a proto víš, že ho máš kontrolova nějak sám. Za mě jsou self-signed certy v dnešním použití bezpečnější, protože uživatele vyzvou k důvěře.

Až na to, že v tom relativně malém počtu excesů byly podepsané domény jako github.com. Příště tam bude třeba google.com. To že se to stane nějaké ChuangFujSsl a né žádné renomované CA na tom nic nezmění, protože to bude mít řetězec důvěry až ke kořenovým certifikátům v tvém prohlížeči.

Až na to, že v tom relativně malém počtu excesů byly podepsané domény jako github.com. Příště tam bude třeba google.com.
Ten příklad se vám moc nepovedl. U těchhle domén se na to velice rychle přijde, certifikáty jdou na blacklist a certifikační autorita jako důvěryhodná končí. Google.com je z tohohle pohledu vůbec ta nejhorší možná doména, kterou si útočník může vybrat.

Ty certifikáty budou v CT logu. Prohlížeč oběti samozřejmě zjistí, že ty certifikáty nejsou pravé, podle HKPK hlavičky. Pokud tím prohlížečem bude Chrome a uživatel to povolí, vzápětí se to dozví i Google (předpokládám, že ostatní prohlížeče mají podobnou funkci).

U těchhle domén se na to velice rychle přijde, certifikáty jdou na blacklist a certifikační autorita jako důvěryhodná končí. Google.com je z tohohle pohledu vůbec ta nejhorší možná doména, kterou si útočník může vybrat.
A co když není cílem dlouhotrvající útok ale krátké nasbírání dat o které zrovna útočníkovy jde? Myslíte, že google zvládne do 24 hodin účinně zablokovat vadný certifikát? Já tomu moc nevěřím.

A co když není cílem dlouhotrvající útok ale krátké nasbírání dat o které zrovna útočníkovy jde? Myslíte, že google zvládne do 24 hodin účinně zablokovat vadný certifikát? Já tomu moc nevěřím.
Bavíme se o certifikačních autoritách. To, aby Google zjistil, která certifikační autorita certifikát vydala a podnikl proti ní patřičné kroky, není omezeno tím limitem 24 hodin.
A jinak v Chrome ten certifikát nejspíš do 24 hodin zablokovat dokážou, a pokud ta autorita nebude moc natvrdlá, dokáže ten certifikát do 24 hodin dostat na CRL.

Bavíme se o reálné hrozbě vydání špatného certifikátu a jeho účinné revokaci. Po 24 hodinách už můžou být škody obrovské. I 10% uživatelů kteří nepoužívají chrome je velké číslo. A nemáme tu jenom prohlížeče ale například poštovní klienty, nebo server to server komunikaci. V případě prohlížečů dokonce ani nemusí být vidět v adresním řádku prohlížeče, že nejde o EV certifikát, pokud cílem útoku budou třeba google fonty (jako prostředek jak využít nějakou zranitelnost prohlížeče v chybném renderování fontů).

Nikoli, bavíme se tu o certifikačních autoritách. Nejpravděpodobnější případ, jak dojde k vydání špatného certifikátu, je chyba na straně žadatele o certifikát (unikne mu privátní klíč, ověří certifikát pro privátní klíč, který nevlastní, apod.). S tím toho certifikační autorita mnoho udělat nemůže. Řeč pak byla konkrétně o útoku na certifikát pro doménu google.com – s touto doménou asi mnoho poštovních klientů nekomunikuje, a mnoho serverů také ne. Že by na této adrese byly hostované fonty, o tom také nic nevím (fonts.google.com je něco jiného, než google.com).
Pokud chci zneužít nějakou zranitelnost prohlížeče v chybném renderování fontů, nepotřebuju mít font umístěný na doméně google.com s EV certifikátem, ale ten font nahraju prostě na stejnou adresu, na které běží web, přes který tu zranitelnost budu chtít zneužít.

Příkladem google.com jsem neměl namysli zrovna pouze vyhledavač (jako google), ale právě některou z poddomén, třeba formou hvězdičkového certifikátu na *.google.com. Jde o to, že toho google poskytuje hodně.
Co se týče těch fontů, tak musím uživatele přesvědčit, aby na ten web s tím fontem přišel. Když uloupím fonts.google.com, mám tam hned uživatelů miliony. Závisí na cíli útoku co bude lepší. Fonts.google.com bylo první co mne napadlo, ale google toho poskytuje mraky.

Já bych byl rád kdyby protokol důvěry zbytečně nesnižoval důvěru ve spojení s firmou kterou jsem si zvolil. Zrovna google jistě má odborníky a vnitřní předpisy na manipulaci s certifikáty, takže se bojím, že tady implementace protokolu důvěry snižuje důvěryhodnost spojení s googlem možná i o několik řádů (pravděpodobnost problému je o několik řádů vyšší). Proto argument, že největší pravděpodobnost, že za to může žadatel neberu. (Chtěl bych aby zodpovědní žadatelé měli možnost použít řešení, které zbytečně nesnižuje důvěru ve spojení s nimi a tedy i v jejich produkty.)
Jistě, google má spoustu obezliček jak omezení současné implementace PKI obejít, (třeba tím, že hodně lidí používá jeho vlastní prohlížeč), ale to není systémové řešení. To je rovnák na vohejbák, který vznikl právě proto, že google je tak velký cíl, že to řešit musí.

Zrovna google jistě má odborníky a vnitřní předpisy na manipulaci s certifikáty
Vzhledem k tomu, že dnešním CA stačí pro ověření držení domény vystavení souboru na webu nebo přístup ke správné e-mailové schránce, tu chybu může udělat někdo, kdo s certifikáty vůbec nepřichází do styku – stačí, když má právo nahrát na web vhodně pojmenovaný soubor.

Jistě, google má spoustu obezliček jak omezení současné implementace PKI obejít, (třeba tím, že hodně lidí používá jeho vlastní prohlížeč), ale to není systémové řešení. To je rovnák na vohejbák, který vznikl právě proto, že google je tak velký cíl, že to řešit musí.
S tím naprosto souhlasím. Původně jsem chtěl jenom poukázat na to, že právě proto je Google špatný příklad, protože snad nikdo jiný nemá tolik možností bránit se útokům na certifikáty jako právě Google.