Názory k článku SSL není bezpečné, ukazuje případ Comodo
-
MilanK (neregistrovaný)
Tedy takto zmatený článek bez informační hodnoty jsem od Petra snad ještě nečetl... Namátkou: SSL používá symetrické šifry, asymetrickými algoritmy se přeci "jen" domlovají komunikující strany na klíči k symetrické šifře. Popisovaný problémem není slabost SSL, ale PKI. Navíc tu zazněla zprávička, že FF4 měl proti podvrženým certifikátům docela účinnou ochranu i před tím blacklistem atd.
-
belzebub (neregistrovaný)
Autor v clanku uvadi ze "znalci prominou" - takze evidentne (a z hlediska firmy internet info zcela pochopitelne) se jedna o clanek urceny NEJEN odbornikum.
Takze male zjednoduseni urcite neni problem a mozna prave diky nemu si clanek prectou a pochopi i ne-IT odbornici, coz bychom my, IT-aci, meli uvitat, protoze neni nic lepsiho nez kdyz maji i obchodnici a sefove jasno v tom k cemu je SSL a ze to neni samospasne. -
MilanK (neregistrovaný)
Tak na Lupu by se takový článek o tom, že "Hacker prolomil oblíběné šifrování na webu", určitě hodil, ale místní čtenáři snad vědí, že k ničemu takovému nedošlo. Uvítal bych spíš článek na téma, jak se těmto stále častěji používaným podvodným certifikátům bránit, proč je lepší ukládat certifikáty do DNS, v jaké fázi je standardizace takových technik... A taky bych trochu vysvětlil tu poslední zfalšovanou "doménu" `global trustee'.
-
ubx (neregistrovaný)
Presne tento princip vyuzivaju bezpecnostne brany na to, aby mohli kontrolovat obsah ssl traffic. Certifikat brany sa v ramci firmy "podvrhne" cez policy v active directory bezny user si nic nevsimne (pokial nepouziva certificate patrol, neodklada a nekontroluje si zakazdym si fingreprinty a podobne veci - co asi nerobi vobec nikto :-) ).
Druha vec je, ze prave tento "feature" vyzivaju najma vlady, ktore si od CA vydupali svoje kopie certifikatov a smiruju, co chcu. Vid posledny pripad v Rakusku, ktory sa prevalil len vdaka tomu, ze smirovacie servery nestihali s vykonom. -
MilanK (neregistrovaný)
Bylo to jen nepřesně formulované. Nechají si vystavit další (nový) certifikát pro stejnou doménu, jakou chtějí odposlouchávat (např. mail.google.com) nebo dokonce certifikát podřízené certifikační autority, kterým si pak mohou ty nové certifikáty generovat třeba i v reálném čase.
-
Takže když se připojím třeba k mail.google.com, tak nejenže mi vláda občas podvrhne DNS záznamy, ale ještě i certifikát, aby se mohla kouknout, s kým si mailuju.
A jako napotvoru si toho nikdo nevšimne, že jednou je mail.google.com certifikovaný autoritou TrustedAuth a jindy EvilGovAuth.
Ale jinak máte bujnou fantazii, to zas jo :)
-
>> DNSku není potřeba podvrhovat
A jakým způsobem to funguje?
Dejme tomu, že čtu maily na https://mail.google.com. Jakým způsobem útočník, který je na stejné LAN, provede MITM útok?
-
MilanK (neregistrovaný)
http://ettercap.sourceforge.net umí:
- přesměrovat na sebe provoz - tj. udělat ze sebe MITM - technikou ARP spoofing
- transparentní SSL proxy, která vystavuje certifikáty za běhu na požádání (on-the-fly)Ano, ARP spoofing dokáže odfiltrovat skoro každý L2+ switch, ale kdo takové filtry používá? V Čechách?
-
Dobrá, takže za podmínky, že:
1. vláda ovládá nějakou CA, kterou mám nastavenou jako trusted
2. má roota na nějakém stroji v mé lokální LAN
3. nemám switch nastaven na obranu proti ARP spoofingu
4. nevšimnu si, že se mění klíč mail.google.com (protože se nepohybuju jenom ve své - napadené - síti, ale i v jiných)si vláda může přečíst mail, ve kterém Frantovi píšu, že ta včerejší pařba byla hustá.
Tak s takovým rizikem jsem ochoten se smířit :)
-
>> Nejtěžší je samozřejmě (1)
Já bych to řekl jinak: kdo zvládne 2), ten s velkou pravděpodobností zvládne získat roota i na mém počítači a nepotřebuje dělat ostatní opičky :)
>> Ani není správné psát "nevšimnu si", ale "nepoužívám žádné přídavné mechanismy, které by si toho všimly"
No já jsem to myslel tak, že kdyby si výrobci prohlížečů byli vědomi, jak je práce s certifikáty důležitá a implementovali něco lepšího (viz zelená/oranžová/červená níž), tak by žádné spešl nástroje nebyly potřeba.
-
Obávam se, že to není bujná fantazie, ale realita. Nikdo netvrdí, že se to děje v nějakém masovém měřítku... Navíc se nejedná o EvilGovAuth, ale o certifikační autoritu, která je normálně umístěna v úložišti certifikátů, takže pokud váš prohlížeč nedělá kontrolu podobně jako Google Chrome, který hlásí změnu certifikátu, tak si ani ničeho nevšimnete.
Prostě ty desítky CA certifikátů, které máte v systému jako důvěryhodné, jsou největším selháním PKI modelu (resp. fakt, že jsou všechny stejně důvěryhodné).
Jak už to někdo v komentářích psal, tak se nám povedlo na IETF založit pracovní skupinu DANE WG, která se snaží převést důvěru zpět tam kam patří - do rukou držitele domény.
O.
-
>> takže pokud váš prohlížeč nedělá kontrolu podobně jako Google Chrome
Když já právě jako na potvoru většinou používám Chrome :)
>> Prostě ty desítky CA certifikátů, které máte v systému jako důvěryhodné, jsou největším selháním PKI modelu (resp. fakt, že jsou všechny stejně důvěryhodné).
S tím bezvýhradně souhlasím.
-
benzin (neregistrovaný)
Presne tak. To mi prijde na celem PKI vesele, ze ja sice vidim ze certifikat je vydany certifikacni autoritou, ale uz se nedozvim, jestli je pouzivan na spravne domene. Takze staci jediny scizeny certifikat kohokoli a uzivatel nic nepozna (tedy pokud nezna jmeno spolecnosti, ktera ma pravy certifikat pro domenu a nezkontroluje ho).
Takze je to presne jako obcanka. A skutecne je kazdy kdo ma nejakou obcanku duveryhodny? (Btw. na obcance je aspon fotka)
-
BoB2176 (neregistrovaný)
se nedozvim, jestli je pouzivan na spravne domene
No to tedy poznáte - každý certifikát má v sobě uvedeny (nezměnitelně) jména, ke kterým náleží.
staci jediny scizeny certifikat kohokoli a uzivatel nic nepozna
Nestačí zcizit jeden certifikát, protože ten nebude mít nastaven (opět nezměnitelně) příznak, že může vydávat další certifikáty.
Omlouvám se, ale o PKI zhola nic nevíte...
-
BoB2176 (neregistrovaný)
Prohlášení že "SSL není bezpečné" je asi stejné, jako říkat "občankám se nadá věřit, protože si někdo nechal vyrobit falešnou". Jednoduše velmi silné tvrzení, které se nezakládá na pravdě.
Ano, případ Comodo je problémem, není to však problémem PKI (ne SSL), ale lidského faktoru. Kterého neinteligenta (neinteligenti prominou) napadlo použít pro účet s vysokými právy tak slabé heslo?
Naopak se ukázalo, že PKI je bezpečný koncept, protože se s tímto typem útoku dokázal velmi dobře vypořádat.
-
Luboš (neregistrovaný)
A jak se s tím prosímtě PKI vyrovnal? Tím, že výrobci koncových aplikací ty certifikáty natvrdo odmítají? To je teda řešení na jedničku a hlavně naprosto obchází PKI, prostě situaci musel zachránit někdo jiný. Kdyby to zůstalo na PKI, tak pořád ještě čekáme, kdy nás někdo napadne.
-
Jirka W (neregistrovaný)
> Ale to tvrdé odmítání je také princip PKI.
To právě není princip PKI. Princip PKI je ověřit důvěryhodnost certifikátu standardní cestou (CRL, OCSP) a pokud je ověření nepodaří, tak se má certifikát prohlásit za nedůvěryhodný.
To, že SSL tento mechanismus ignoruje a při výpadku CRL serveru je vše důvěryhodné, a že tvůrci prohlížečů musí do kódu zabudovávat seznam nedůvěryhodných certifikáty natvrdo, to rozhodně není princip PKI.
-
Mickey Mouse (neregistrovaný)
Je mi líto, ale pletete se. Odmítání certifikátů, kterým nechci věřit JE standardní mechanismus PKI. Ověřování podle CRL a důvěra nějaké autoritě je jen jedním z mechanismů. Zrovna tak, jako je možná přímá výměna certifikátů a důvěra jednotlivému certifikátu nedůvěryhodné autority, je také možné nedůvěřovat jednotlivému certifikátu důvěryhodné autority.
Ostatně OS a prohlížeče na to pamatují a umožňují ruční správu certifikátů.
Je nutné také dodat, že pokud prohlížeč nezíská CRL a potom důvěřuje takovému certifikátu, je to minimálně chyba v implementaci, protože PKI standardy doporučují v takovém případu certifikátu NEdůvěřovat. -
>> Prohlášení že "SSL není bezpečné" [...] Jednoduše velmi silné tvrzení, které se nezakládá na pravdě. [...] Kterého neinteligenta (neinteligenti prominou) napadlo použít pro účet s vysokými právy tak slabé heslo?
Tyhle dvě věty si trochu odporují. Bezpečnost SSL kriticky závisí na PKI. PKI závisí na výběru skutečně důvěryhodných autorit. Výběr autorit za většinu z nás dělají výrobci prohlížečů a OS.
No a jestliže každý z nás si ochotně nechal výrobcem prohlížeče/OS nakukat, že je důvěryhodnou autoritou firma, kde klidně "nějakého neinteligenta napadne použít pro účet s vysokými právy tak slabé heslo", tak zjevně PKI má nějakou slabinu - a tím tuto slabinu má i SSL. Samozřejmě se můžeme dohadovat, jak je ta slabina závažná.
Dan Lukeš na to má docela radikální názor:
Pokud máte v browseru autority oprávněné certifikovat klíče WWW serverů, je celková míra spolehlivosti jakékoliv HTTPS komunikace rovna spolehlivosti té nejméně důvěryhodné autority. S předinstalovanou sadou autorit obou majoritních prohlížečů je pak bezpečnost opravdu nulová.
http://www.lupa.cz/clanky/https-bezpecnost-jen-pro-vyvolene/ -
BoB2176 (neregistrovaný)
Budete prohlašovat, že operační systém XYZ není bezpečný, když si uživatel jako své heslo zvolí "admin"? Budete prohlašovat, že platit penězma není bezpečné, když se někomu povede udat padělek?
Pokud je na výše uvedené otázky odpověď ANO, potom je pravda, že "SSL není bezpečné" a zároveň je pravda "nic není bezpečné". Nic by nebylo bezpečné už z principu, protože vše nakonec tvoří a ovládají jen lidé, kteří mohou dělat chyby - a taky je dělají.
-
>> Budete prohlašovat, že operační systém XYZ není bezpečný, když si uživatel jako své heslo zvolí "admin"?
Ano, protože bezpečnost je vlastnost systému jako celku. Takže konkrétní počítač není bezpečný, pokud je na něm heslo "admin".
Bezpečnost PKI kriticky závisí na procedurách, podle kterých se CA chová. A jestliže jsou ty procedury nastaveny špatně, nebo je někdo nedodržuje, pak PKI JAKO CELEK (!) není bezpečné.
Nebo budete prohlašovat, že je bezpečné PKI, kde jedna z trusted autorit vydá certifikát na cokoli komukoli?
-
janek (neregistrovaný)
Tady se nabízí otázka, jak podle vás udělat systém, který nebude závislý na lidské chybě? Ten systém selhal na lidech a ne na tom, že by byl špatně navržený. IMHO jediná možnost jak se z toho problému poučit je právě vylepšit a zrychlit mechanismus zneplatnění ukradených certifikátů.
-
benzin (neregistrovaný)
Vzdycky je otazka dopadu. Kromne samotne miry bespecnosti je podle mne dulezita i zneuzitelnost. A u SSL je mozne zasahnout obrovske mnozstvi lidi najednou. Navic, zatimco Vasi padelanou obcanku muze smysluplne pouzit jenom padelatel ve vasi zemi (mozna v EU) a padelane penize muzete dostat jenom od nekoh s nimz jste v kontaktu. Tak internetovy utok muze provest kdokoli odkudkoli a muze byt veden kamkoli. To bych videl jako hlavni rozdil.
-
Mara (neregistrovaný)
Budete prohlašovat, že operační systém XYZ není bezpečný, když si uživatel jako své heslo zvolí "admin"? Budete prohlašovat, že platit penězma není bezpečné, když se někomu povede udat padělek?
Jo. Jestli si můžu získat certifikát, že jsem Tvoje banka (protože pouhý uživatel zvolil "admin", resp. gtadmin/globaltrust), pak věřit takové autentizaci (SSL) není bezpečné. Nejde o padělek bankovky, ale celé banky.
Pokud navíc certifikát nelze spolehlivě odvolat (ještě před navázáním spojení), pak PKI selhalo jako koncept.
Pokud je na výše uvedené otázky odpověď ANO, potom je pravda, že "SSL není bezpečné" a zároveň je pravda "nic není bezpečné". Nic by nebylo bezpečné už z principu, protože vše nakonec tvoří a ovládají jen lidé, kteří mohou dělat chyby - a taky je dělají.
Jo. PKI a SSL má evidentně problém. Někdo se tím snaží zabývat a řešit to. BoB2176 raději pokrčí rameny a se slovy "nic není bezpečné" si napíše PIN přímo na platební kartu, že?
-
kubik (neregistrovaný)
Velmi rád bych měl možnost relativně jednoduše globálně změnit seznam důvěryhodných CA ve Firefoxu (přidat vlastní CA a vyházet některé jiné). Pokud jde o Firefox 3 tak jsem na to nepřišel jak to globálně (pro všechny) uživatele nastavit (je to tam až příliš zadrátované). Je na tom Firefox 4 jinak? Také mi schází možnost dát důvěru nějaké CA jen omezeně - tedy jen na nějaký seznam "domén" (CN).
Hodně trpím na Androidu. Tam při přístupu ve vestavěném prohlížeči na stránky podepsané vlastní CA musím neustále odklepávat, že certifikátu důvěřuji (a jsem tak vlastně nucen neustále kontrolovat jeho otisk). Nevím jak tam přidat vlastní CA - jde to vůbec?
-
Spíš by nebylo od věci, kdyby prohlížeče umožňovaly nějaký "user-managed security mode", ve kterém by fungovaly třeba takhle nějak (určitě by odborníci vymysleli vychytanější postupy):
1. CAs by byly roztříděné podle důvěryhodnosti do nějakých stupňů, přičemž si můžu zvolit stupeň, nad který automaticky důvěřuju. Paranoici zvolí "nevěřit nikomu".
2. když uvidím nový certifikát, je mi oznámeno, jaký stupeň má CA, která ho podepsala, a můžu si zvolit, jestli certifikátu chci věřit nebo ne
3. když půjdu na tu stránku podruhé, tak jestliže se certifikát nezměnil, nic mě neotravuje a postupuje se podle předchozí volby
4. jestliže se certifikát změnil, pak jsem na to upozorněn, zvlášť když se tak stalo podezřele brzo před expirací předchozího.
5. když poprvé uvidím nějaký certifikát vydaný nějakou CA, které už důvěřuji u jiného certifikátu, tak jsem na to upozorněn (+ existuje volba "automaticky důvěřovat", která se mě potom už na nic neptá a důvěřuje všem certifikátům vydaným touhle CA)Implementováno by to nutně nemuselo být jako otravující vyskakovací okýnko. Mohlo by se použít třeba to, co je teď - non-trusted přenos by byl označenej zčervenáním adresního řádku a teprve když bych na to kliknul (dám najevo, že mi jde o bezpečnost), tak by proběhla procedura popsaná výš a potom by řádek zezelenal :) Nebo by třeba mohl být adresní řádek oranžový u certifikátů, kterým sice explicitně nevěřím, ale jsou platně podepsané.
-
Zvýší se (potencionálně) bezpečnost tím, že se rozliší zelený stav (explicitně trusted certifikáty), oranžový (dnešní trusted) a červený (něco je špatně).
Kdo chce vysokou bezpečnost, dá třeba do zelených jenom ty, u kterých si ověří fingerprint. Tím má poměrně slušnou jistotu, že zelené jsou opravdu důvěryhodné, zatímco dneska ví jenom tolik, že zeleným má ochotu důvěřovat vydavatel browseru/OS.
-
janek (neregistrovaný)
Ale to je řešení pro pár lidí. Většina lidí neumí ověřovat certifikáty a z těch co to umí s tím většina lidí nebude chtít ztrácet čas. Navíc přibude problém s bezpečným kanálem pro ověření fingerprintu (pokud nevěřím CA, tak těžko budu věřit fingerprintu vystavenému někde na webu).
-
>> Ale to je řešení pro pár lidí.
No tak zaprvé by bylo fajn i to, kdyby takovou bezpečnost mohl mít někdo, kdo ji mít chce, zatímco dneska ji mít v podstatě nemůže (nebo alespoň ne tak komfortně).
Ale stejně si myslím, že na tom není nic tak nepochopitelného pro kohokoli. Příklad:
Mám tři kritické aplikace (bankovnictví, školní administrativa, nějaký e-government a stránky, odkud stahuju updaty prohlížeče a OS). Jsem si vědom, že nabourání přístupu do těchto aplikací by mě silně poškodilo, takže jsem ochoten si ověřit fingerprint -- např. datovky pokud si pamatuju posílají fingerprint v dopise, stejně tak to může udělat škola a banka mi fingerprint dá při zakládání účtu. Trochu horší je to s vydavatelem OS a browseru. Tam bych nejspíš musel věřit fingerprintu z webu. Naštěstí mi to ale stačí jednou a pravděpodobnost kompromitace webu zrovna v době, kdy si tam jednou za život přečtu fingerprint, je přijatelně nízká.
U ostatních aplikací mi bude stačit "oranžová" úroveň důvěryhodnosti.
Taky je potřeba si uvědomit, že při tomhle principu je u úrovně "zelená" podstatný hlavně fingerprint. Dneska lidi neumí posoudit důvěryhodnost certifikátu, protože na ně prohlížeč vyblafne tisíce informací o fp klíče, vydavateli, fp klíče vydavatele, různý doplňující informace...
-
limit_false (neregistrovaný)
Firefox: jednou se to naklika v Preferences->Advanced->View certificates, pak staci ostatnim uzivatelum skopirovat cert8.db (~/.mozilla/firefox/_profilename_.default/cert8.db) do jejich profilu. Globalne to AFAIK nejde. Skopirovanim/prepsanim uzivatelova cert8.db se taky ztrati certifikaty a cert autority, kterym uzivatel veril (nebo rucne doinstaloval).
Android: telefon musi byt rootnutej (mozna na novsich to jde i jinak): http://www.root.cz/clanky/verite-opravdu-jen-duveryhodnym-certifikacnim-autoritam/nazory/359445/
(je tam ukazano deletovani, proste misto deletovani se udela keytool -importcert) -
limit_false (neregistrovaný)
Vzhledem k tomu, ze strikni kontrolu nema zadny browser by default (ve FF lze nastavit bud pres Preferences->Advanced->Encryption->Validation), je to tak trocha na dve veci.
Revocation doesn't work:
http://www.imperialviolet.org/2011/03/18/revocation.htmlJak to s oblibou rika Peter Gutmann, je to jako "ptat se ozraleho jestli je ozraly".
A co treba OCSP responder certificate s OCSPNoCheck rozsirenim? Takovy certifikat nelze revokovat.
-
IE9 & Šifrovaná komunikace (neregistrovaný)
Jak je to u nového IE9? Jak poznám sílu aktuálně používaného šifrování? Je například komunikace zabezpečená šifrou slabší než 128bit nějak označena? Informací málo (pardon překlep INFORMACE ŽÁDNÉ) a navíc chaos!
Zkuste například https://encrypted.google.com/ Z vlastností dané web-stránky se dozvíte pouze, že komunikace(připojení) je šifrováno.
Zkuste https://www.covertbrowsing.com/ Z vlastností dané web-stránky se dozvíte, že jde o připojení "TLS 1.0, AES s 128bitovým šifrováním (Vysoká); RSA s 2048bitovým přenosem" přestože vám před přepnutím do SSL jejich web tvrdil že šifrování bude 256bitové.
Zkuste ale anonymně zabrowsdat třeba na Seznamu, kdekoli. Sílu šifry při tomto anonymním procházení webem vám IE9 opět zatajuje. -
https://www.covertbrowsing.com/ ve FF: AES-256. IE8 hlasi TLS 1.0, RC4 s 128bitovým šifrováním (Vysoká); RSA s 2048bitovým přenosem. Proc?
-
Kecka (neregistrovaný)
V současnosti testuji weby pomocí SSL Server Test od Qualys SSL Labs. Můžete si nechat zobrazit i podporované protokoly a způsoby šifrování.
Vyzkoušel jsem i pár serverů s odvolaným certifikátem. Dotazy:
1. Jak povolím navštívít server jehož certifikát není platný, byl odvolán, aniž bych musel tento certifikát označit za důvěryhodný, nebo musel vypnout kontrolu certifikátů? Někdy se to může hodit.
2. V IE9 přibyla volba ""Blokovat nezabezpečené bitové kopie s ostatním smýšeným obsahem". Mate mne to slovíčko "bitové", jde o klasické blokování smíšeného obsahu bez dotazu? Od verze IE9, při aktivní této volbě, se jen zjeví informační lišta a není vyžadována interakce/potvrzení.
Budu s IE, ohledně této volby ještě experimentovat, ale nemohu hned. -
Kecka (neregistrovaný)
Tak jsem testoval tu volbu "Blokovat nezabezpečené bitové kopie s ostatním smýšeným obsahem" a žádná změna, stále je zobrazono upozornění s možností zobrazit i smýšený obsah.
podle mne to má na svědomí nová volba (zvlášť pro každou zónu zabezpečení) - "Zobrazit smýšený obsah".Pokud tyto dvě volby nějak koexistují, měl by to MS vysvětlit!
Vůbec, naposledy MS řádně vysvětlil co která volba dělá u IE 5.01, něktří uživatelé IE dodnes nemají ani základní přehled o svém browseru.**
Také jsem zaznamenal novou volbu "Weby obsahu ve více omezené zóně mohou přejít do této zóny". Nedovedu si rychle vybavit jak to fungovalo u IE8, ale tam jste měli, narozdíl od IE9, neustále přehled o tom v jaké zóně se pohybujete.
Také si nemohu být, bez testů jistý zda to znamená, to co čtu a zda se to týká jen odkazů, jednotlivých rámců nebo prostě částí webové stránky složené z vícero zdrojů.
Myslím že seznámení s IE9 bude probíhat mnohem déle než s IE8 a to mi trvalo měsíc. Microsoft to uživatelům vůbec neusnadňuje.Kdyby někdo znal hodnotný zdroj informací o IE9, i v angličtině, nechte zde prosím odkaz. Určitě se sem ještě vrátím.
P.S. Lze-li upravit GUI, například pomocí nedefinovaných zásahů do registru, nebo zapnutím virtuálních doplňků, obohatit stavový řádek,... tyto informace vítám obzvlášť.
-
Vždycky když někomu vysvětluji princip důvěry a důvěryhodných certifikačních autorit nezapomenu dodat, že tedy nejde o "důvěryhodné weby" ale o weby kterým důvěřuje Microsoft resp. výrobce software plus weby, kterým důvěřuje uživatel nebo jeho viry :)
Osobně si myslím že problém není v tom, že lze nějak získat podvodný "důvěryhodný" certifikát, ale v tom, že máme do počítače nacpány desítky různých "autorit" , které se velmi liší ve svých bezpečnostních politikách a že BFU je od výběru těchto autorit úplně odtržen a tím pádem vůbec ten sytém nemůže nikdy pochopit. A pokud někdo něco nechápe, nikdy to nemůže dobře používat.Jinak po tomto "humbuku" očekávám tlak certifikačního trustu na růst ceny za certifikáty a snižování již tak nesmyslně krátké doby expirace.
-
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.
-
limit_false (neregistrovaný)
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ě. -
Subber (neregistrovaný)
Ale zase pokud muze utocnik manipulovat s internetovymi servery s obsahem a poslat chybu 500 pri zadosti o list, muze take falsovat aktualizacni servery prohlizecu a tim k aktualizaci na prohlizec ktery ma tyto certifikaty blokovane nedojde. Mozna ze by se dala podstrcit v tomhle pripade i nejaka fake verze. Je to proste kolotoc :).
-
prdlous (neregistrovaný)
Procetl jsem si ty jeho "clanky" na pastebinu.
Hoch o sobe prohlasuje, ze ma znalosti 1000 programatoru, ze tohle dokazal ve 21 letech apod... To, ze ve 21 tohle udelal mi neprijde jako nic zvlastniho - lidi maji nejlepsi napady a "drajv" prave v tom veku. Ostatne, cely to stoji i pada na Italskym pristupu k zabezpeceni, coz jsem si mohl osahat na vlastni kuzi. Kazda druha wifina tady ma stejny heslo jako ESSID pristupovyho bodu.
ČLÁNKY DO MAILU
