Vlákno názorů k článku Protokoly chránící proti nedůsledným a nebezpečným CA od xm - Popsané aktivity vidím jako dobré. Každopádně je ještě...
-
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ý podporovatelVzhledem 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
ČLÁNKY DO MAILU