Názory k článku Protokoly chránící proti nedůsledným a nebezpečným CA
-
Odkaz na crossbear doplnek vede nekam do ztracena: "We're sorry, but we can't find what you're looking for."
"„všechny certifikáty vydané od CA budou ve veřejně přístupném logu“. Tento log musí mít také vlastnost append-only, nesmí být možné falšovat minulost."
Zajimalo by mne, jak tohle zajistit. Snad leda tesat do zuly na nejakem frekventovanem namesti, kde by si pokusu o zfalsovani snad nekdo vsiml.
-
Ondrej Mikle (neregistrovaný)
Casti Merklovho stromu budou podepsany klicem spravce logu (v zasade by stacilo podepsat koren). Je uz i nejaka alpha implementace:
https://code.google.com/p/certificate-transparency/
Navic je v repozitari draft RFC dokumentu popisujici strukuru a algoritmy, vygenerovany text z xml2rfc: http://pastie.org/3393836
-
Filip JirsákStříbrný podporovatelNapříklad důvěryhodná třetí strana, která bude log pravidelně časově razítkovat. Každý, koho ten log bude zajímat, si jeho otisk může v pravidelném ukládat sám. Vše okolo CA se netočí kolem toho, jak podvodu zabránit, ale jak podvod odhalit.
-
Filip JirsákStříbrný podporovatel
Nemusíte mít jedinou autoritu, klidně jich může být víc a můžete vyžadovat podpis třeba alespoň od třech. Stejně vždycky musíte důvěřovat spoustě různých institucí a lidí, takže je potřeba řešit, komu důvěřovat a komu ne.
Na CA se nic neprovalilo, ten koncept byl odjakživa postaven tak, že určitým CA primárně důvěřujete, ale pořád je můžete kontrolovat a pokud udělají něco špatně, můžete chybně vydané certifikáty kdykoli řešit, aniž byste tím omezil důvěru v ostatní certifikáty. Pokud si někdo myslel, že CA jsou absolutně bezpečné, je to jeho problém, ne problém koncepce.
-
k nefunkcnim odkazum ma Crossbear:
"Mozilla gave us a valuable review, even though it means the add-on will be disabled for a few days. We'll address the issues and re-submit."
"Mozilla wants us to get a CA-issued cert for our server. We can comply with that but it will take a week to get the cert from DFN"
oba tweety z 8. února
zdroj: https://twitter.com/#!/crossbearteam -
Ondrej Mikle (neregistrovaný)
Pridavani na addons.mozilla.org funguje trocha jinak:
1. clovek tam neco da
2. je to v stavu "warning, muzete si to stahnout po odklikani nekolika warningu, ale Mozilla to jeste neprohledla" (plus zavisi od dalsich faktoru, jako napr. nastaveni nejakych specialnich promennych v about:config)
3. Mozilla udela review
4. pak se addon se bud povoli nebo se stahne, nasleduje diskuse s developerem && goto 3Treba kolega mel onehda problem s reviewem DNSSEC Validatoru, protoze se Mozille nelibilo, ze ma binarni komponentu. I kdyz se nejprve ptal, jak to ma teda udelat (bez binarni komponenty by to nefungovalo), nakodil to podle doporuceni z mozilliho mailing listu. Na jedne strane je to dobre, aby se tam nedostaval jen tak jednoduse malware, na druhe strane holt politika :-)
V Chrome store to bylo jednodussi (pro Chrome verzi), stacilo zaplatit uvodni poplatek ($5), podepsat smlouvu a review byl celkem rychly (cca. tyden). Ale je tezke rici, zda to bylo treba kvuli tomu, ze uz DNSSEC Validator byl schvalen predtim Mozillou, nebo tim, ze CZ.NIC znaji z predchozi spoluprace.
-
xm (neregistrovaný)
Popsané aktivity vidím jako dobré. Každopádně je ještě kus cesty než se nějaká dopracuje a ujme. I když k tomu dojde, stále mi chybí možnost definovat ručně přímo v prohlížeči, že chci, aby konkrétní servery (či domény) měly podepsané certifikáty jedině mnou definovanýma CA. Prostě chci například nastavit, že tyhle servery může podepsat jedině tahle CA (třeba nějaká vlastní) a žádná jiná. Bezpečnou (třeba i nějakou z ruky do ruky) distribuci certifikátu CA i s informací jakých se týká serverů či domén si zajistím. Co je hlavní, že pak můžu být u příslušných serverů (na dobře nastavených klientských stanicích u kterých věřím, že nejsou kompromitovány) v klidu (pokud tedy nepadne přímo nějaká asymetrická krypto metoda).
Je to přece primitivní a nechápu proč to prohlížeče již dávno neumožňují - nebo to má někdo implementováno?
-
Palo M. (neregistrovaný)
Pre Firefox je rozsirenie "Certificate Patrol" - to sa pyta vzdy pri zmene certifikatu, ci moze byt alebo nie. Nie je to sice celkom to co popisujes, ale ako proof-of-concept moze byt.
Ked ti to tak chyba, mozes sa realizovat a napisat svoje rozsirenie, ktore bude mat zoznam stranok s pevne priradenymi konkretnymi CA... Je to predsa tak primitivne... -
Akorat je problem, ze spousta webu je spravovana kreteny, kteri maji na kazdem serveru jiny certifikat a podle toho, kam was zrovna hodi, se vam furt meni certifikat a vy to pak akorat furt odklikavate a akorat to otravuje a bezpecnost se tim nezvedne, protoze kontrolovat to proti nejakym fingerprintum ve vasem notysku pri kazdem reloadu stranky nebudete.
To same s ssl pri stahovani mailu. Treba na Google leckdy i pri kazdem stazeni mailu to hlasi zmenu certifikatu. Takze zabezpeceni je dobre tak na to, ze si to soused, co vam crackl wifi asi neodchyti, ale vam to urcite nezajisti, ze se pripojujete na spravny server, kdyz v tech certifikatech maji takovy chliv.
-
Filip JirsákStříbrný podporovatel
Vzhledem k tomu, že tak pořád řešíte, komu důvěřovat, mohlo by vás napadnout, že jeden certifikát na jeden server je bezpečnější, než jeden certifikát pro n serverů.
-
Tak to by mne tedy nenapadlo. Protoze kdyz si nainstaluji software, ktery hlasi zmenu certifikatu, tak se jeho hlaskami budu zabyvat, pokud vykrikne jednou za rok, kdyz vymeni certifikat, ale urcite ne kazdych 5 minut, protoze to bych nedelal nic jineho. Cely smysl hlaseni zmeny jde do haje.
U pristupu na mail treba na Google pak je asi problem v tom, ze obcas vymenuji certifikaty, ale nekdy nejsou schopni to udelat na vsech serverech v rozumne kratke dobe, ale trva jim to i nekolik tydnu. Client pak rve pri kazdem pristupu na pop a jeste kvuli tomu zustane viset stahovani, dokud to neodklepnu. Po par tydnech pak je pokoj, az do pristi vymeny.
-
Filip JirsákStříbrný podporovatel
HTTPS je postaven na konceptu certifikátů, ne na konceptu veřejných klíčů (jako třeba SSH). Takže software na hlášení změn certifikátů pro HTTPS moc smysl nedává. Když si nainstalujete nesmyslný software, nemůžete se divit, že dělá nesmysly.
-
Ondrej Mikle (neregistrovaný)
V Certificate Patrol lze zaskrtnout, aby se pro site x.y.z hlasily zmeny jen kdyz se zmeni CA.
CDN sluzby s mnoha certifikaty jsou realitou. Ale je nutne si uvedomit, ze je lepsi pro vicero stroju mit vicero certifikatu s ruznymi klici, protoze napadeni jednoho stroje pak "nezbori" celou CDN. Proste sdileni klicu az na nejake vzacne pripady neni dobry napad.
Google treba pouziva snad uz jen jednu stejnou sadu certifikatu pro *.gstatic.com, *.google.com, *.youtube.com, meni se jenom klice a doba platnosti.
BTW udelat zmenu do Certificate Patrol, aby se choval vice jako Convergence (tj. nehlasil uz odsouhlasene certifikaty) by nemelo byt az tak tezky. Ale nenasel jsem zatim cas to prepsat (a k javascriptu vzdy pristupuji jenom v HAZMAT obleku :-))
Nebo by slo do Certificate Patrol doimplementovat "pinning" podle klicu (to by bylo mirne narocnejsi, ale porad to jde nakodit bez zasadnich problemu).
-
> CDN sluzby s mnoha certifikaty jsou realitou. Ale je nutne si uvedomit, ze je lepsi pro vicero stroju mit vicero certifikatu s ruznymi klici, protoze napadeni jednoho stroje pak "nezbori" celou CDN.
Coz mne ale, jako uzivatele stavi do situace, kdy neni v mych silach certifikaty overovat. Stavaji se tak, podobne jako ssl certifikaty u mailu, veci, ktera mne ochrani leda pred smirujicim sousedem v pripadech, ze bych nemel zabezpecenou sit. Nikoliv pred sulinem, ktery ma nekde na ceste router.
-
Ondrej Mikle (neregistrovaný)
> Coz mne ale, jako uzivatele stavi do situace, kdy neni v mych silach certifikaty overovat.
No, to nekdy zmate i lidi dlouho pusobici v oboru, viz http://dankaminsky.com/2011/08/31/notnotar/
Logika za vsemi protokoly v clanku je: operator serveru x.y.z vi nejlepe, jaky certifikat ma server mit a proto by mel mit nejvetsi kontrolu nad tim, jake certifikaty povoli.
Z predchoziho clanku "SSL divocina...": studii CDN sluzeb jsem delal proto, aby se zjistila skutecna situace a slo z toho vyvodit chovani pro minimalizaci rizika.
Ve zkratce: u vetsich CDN sluzeb (jako Google) je sledovani autority vydavajici certikat postacujici (s rozumnou mirou risku staci i na state-level attacker, jako je Iran nebo Cina).
Osobni nazor: Google nabral spoustu velmi schopnych lidi jako Adam Langley, Ben Laurie, Chris Palmer atd., takze z profesionalni stranky nelze nic vycitat (plus doporucuji se podivat, co prispeli do OpenSSL nebo jinych open-source projektu).
Kdysi jsem si delal srandu, ze kdyz zacne 3. svetova, tak USA anektuje Google. Ted bych spis rekl, ze Google anektuje USA ;-) Zatim vykazuji vysokou odolnost proti statnim zasahum (ale to je na jinou, delsi debatu).
-
Filip JirsákStříbrný podporovatel
<blockquote>Coz mne ale, jako uzivatele stavi do situace, kdy neni v mych silach certifikaty overovat.</blockquote>
Pořád si to pletete. Koncept CA je postaven na tom, že důvěřujete certifikační autoritě. Takže ověřujete kořenový certifikát CA, a ty se zase nemění tak často.Pokud chcete ověřovat každý jednotlivý veřejný klíč serveru, budete muset přijít s novým protokolem, který nebude využívat CA, ale jen veřejné klíče. Kombinace obojího (ověřování veřejného klíče, ale ten bude zároveň součástí certifikátu) je sice technicky možná, ale mít tam tu CA je pak zbytečné.
Jinak bych docela rád viděl, jak ty jednotlivé certifikáty Google ověřujete. To s každým novým certifikátem voláte někam do USA a necháváte si nadiktovat jeho otisk? A nebo prostě jenom zkontrolujete, zda je vydán nějakou důvěryhodnou CA? Pak to ale má jednoduché řešení – vyházejte z úložiště certifikátů nedůvěryhodné CA (což jste ostatně měl udělat už dávno), a problém je vyřešen.
-
Ondrej Mikle (neregistrovaný)
> Takže ověřujete kořenový certifikát CA, a ty se zase nemění tak často.
To je sice pravda, ale bezni TLS klienti (specialne browsery) muzou casto zamenovat certifikaty v retezu a cloveku muzou ukazat uplne jiny chain, nez co poslal server (a skutecne to bezne delaji). Root cert muze byt zamenen za cross-certificate, intermediate certifikatu bezne existuje nekolik verzi.
Treba kdyz se clovek podiva na site A, pak na B, pak zpatky na A, druhy krat mu brower muze ukazat uplne jiny chain (jedine serverovy certifikat nelze zamenit). Vychazi to hlavne z RFC 4158.
Uplne zlo je stahovani certifikatu uvedenych v Authority Information Access extension (jestli je to zlo, by nekteri nesouhlasili, ale je to dalsi skvely zpusob jak zanest nedeterminizmus navic do algoritmu; "AIA chasing" dela treba MS CryptoAPI).
Z toho vyplyva, ze je uplne bezne, ze pro obycejny site existuje treba 16 ruznych validnich retezcu certifikatu (spravna terminologie: "certificate path"). A pri budovani certificate path si musite davat bacha na zacykleni, protoze graf s cross-certifikaty ma cykly ;-)
To uz zpusobilo bolehlav mnoha lidem, v DANE WG se to resilo nekolikrat taky.
> Pokud chcete ověřovat každý jednotlivý veřejný klíč serveru, budete muset přijít s novým protokolem, který nebude využívat CA, ale jen veřejné klíče.
Tohle dela Chrome, nazyvaji to certificate pinning (hashe klicu jsou natvrdo v binarce, ale lze je pridat), byl to jeden z navrhu co jsem tady psal ze by sel celkem jednoduse pridat do Certificate Patrol. Je to taky "mirne kontroverzni", Jim Schaad by na to rekl: "I kind of read this text, despaired and then shrugged off and tried to forget." (duvod: prehrsel ruznych X.509v3 extensions)
Pinning klicem lze udelat v DANE, je to selector type 1.
-
Filip JirsákStříbrný podporovatel
Mně osobně tedy připadá, že zrovna v internetových prohlížečích je problém s certifikáty hlavně úplně na základní úrovni chápání toho, co je vlastně HTTPS -- a všechny další problémy se pak na tohle jenom nabalují. Podle mne by prohlížeč při přístupu na HTTPS měl v základu fungovat úplně stejně, jako s HTTP -- tj. přístup ke stránce považovat za nezabezpečený a neotravovat uživatele žádnými dotazy, varováními a importy certifikátů. Teprve pokud by uživatel opravdu vyžadoval HTTPS, zkontroloval by si ve stavovém řádku, že je certifikát ověřený a platný (ono známé zelené něco), případně by si danou adresu zařadil do seznamu těch, ke kterým chce vždy přistupovat jen přes ověřené HTTPS.
Největší problém dnešních prohlížečů totiž spočívá v tom, že při každém přístupu na HTTPS -- i když uživatele vůbec žádné zabezpečení nezajímá a HTTPS má v adrese jen proto, že byl tak někde vložen odkaz nebo ho server přesměroval -- vyžadují ověření, instalaci certifikátu atd. No a uživatelé pak logicky odklikají cokoli, protože jinak se na web nedostanou. A tak se jim úložiště certifikátů plní různými podivuhodnými přírůstky. Kdyby to fungovalo jak jsem popsal víš, bude mít uživatel v seznamu pár webů, u kterých vyžaduje HTTPS, v úložišti certifikátů bude mít pár autorit, které podepsaly certifikáty těch webů, a většina dnešních problémů s certifikáty přestane mít praktický význam.
-
Lol Phirae (neregistrovaný)
Přesně!!! A vrcholem jsou pak příšernosti typu FF, kde je to tak neskutečně otravné, že by člověk vývojářům nafackoval. Kdysi jsem narazil na web, jehož geniální majitel implementoval HSTS a jaksi zapomněl obnovit certifikát. FF tam člověka vůbec nepustí, ignorování neplatného certifikátu prostě neexistuje. Jinak z hlediska bezpečnosti nevidím pro běžného uživatele žádný rozdíl mezi self-signed a placenými certifikáty, ale patrně je to bezva byznys, takže normálního přístupu se holt nedočkáme. Mám dojem, že Mozilla je přímo placená za to, aby uživatelům v těchto případech co nejvíc otrávila život.
-
Ondrej Mikle (neregistrovaný)
Nafackovat by měli dostáno správci serverů, co si to neumí nakonfigurovat. HSTS v zmíněném případě dělá přesně to, co dělat má.
*Není* úlohou browserů maskovat chyby serverů, i když to už dnes sčásti dělají a výsledkem je bordel: někomu to funguje, jinému to háže warning (v závislosti od stavu cache intermediate certifikátů). Protože server neposílá správný chain.
Zde by měl dostat nafackováno první markeťák, kterého napadlo maskovat chyby serverů v browserech (protože ostatní to potom skopírovali, aby jim "neodcházeli uživatelé") a admini pak ani netuší, že to mají nakonfigurováno blbě.
Nejvtipnější je "drive by shooting" v certificate chainu, kde admin narve třeba 18 certifikátů, "aby to nějak fungovalo" a evidentně nemá potuchy co dělá.
Kdybych měl vyjmenovat všechny faily, co admini dělají, bylo by to veeelmi dlouho. Jeden z oblíbených je CDN certifikát se 100-200 FQDN v SAN extension.
Přitom existují nástroje, které zkontrolují chain serveru a celkem jasně sdělí, kde je problém (např. ten na stránkách Digicertu).
> Jinak z hlediska bezpečnosti nevidím pro běžného uživatele žádný rozdíl mezi self-signed a placenými certifikáty, ale patrně je to bezva byznys, takže normálního přístupu se holt nedočkáme.
To je trocha moc velká generalizace a obecně neplatí. Byly návrhy udělat to jako trust-on-first-use a lze je implementovat třeba jako FF addon.
Jinak Peter Gutmann taky nazývá CA biznis "protection racket" (s něčím s ním lze souhlasit). Viz prezentaci:
http://www.cs.auckland.ac.nz/~pgut001/pubs/prot_browser_users.pdf
-
Ondrej Mikle (neregistrovaný)
Ono je to opacne: pokud utocnik kontroluje DNS server domeny x.y.z, pak si pro domenu x.y.z muze nechat vydat DV-certifikat (domain-validated). CA proste posle mail na adresu typu ssladmin@x.y.z. Jenze utocnik ma v moci MX zaznam, muze to nasmerovat kam chce.
Neplati pro IV, OV, EV certifikaty (identity/organization/extended validation).
Mit falesny SSL/TLS certifikat nestaci ke zmene dat v DNS. Utocnik pro odposlech TLS nemusi mit kontrolu nad DNS, viz pripad Iranu - proste nekde na hranicnim routri DNAT-ovali IP gmailu nekde na svoje stroje. S DNSSEC by museli nejak podvrhnout i podpis TLSA zaznamu nebo dukaz neexistence TLSA zaznamu poskytnutim falesnych NSEC/NSEC3 zaznamu (kde opet musi sfalsovat podpis NSEC/NSEC3).
ČLÁNKY DO MAILU