Názory k článku
SSL není bezpečné, ukazuje případ Comodo

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'.

+1 

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.

Nahodou nemas linku na ten posledny pripad v Rakusku ;-)

>> najma vlady, ktore si od CA vydupali svoje kopie certifikatov a smiruju, co chcu

Neměly by si vlády spíš od vlastníka vydupat klíč? (CA ho nemá) Certifikát jim k ničemu není, to je veřejná informace.

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.

Není to fantazie. Umí to i open source nástroje v podobě MITM útoku (stačí obyčejné připojení na stejné Wi-Fi AP jako "oběť" nebo připojení do stejného switche, DNSku není potřeba podvrhovat).

>> 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?

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?

Ettercap tedy používá aktivnější ARP útok "ARP poisoning"

Takový certifikát, ale nebude důvěryhodný ani z technického hlediska.

mno ale kdyz podvrhnes nejaky duveryhodny certifikat, ktery mas vydupany od CA, tak proc ne?

Nejtěžší je samozřejmě (1), kdo zvládne bod (1), tak obejde (2) a/nebo (3) bez potíží.

Ad (4). Změny certifikátu si skutečně většina lidí nevšimne. Ani není správné psát "nevšimnu si", ale "nepoužívám žádné přídavné mechanismy, které by si toho všimly": Cert patrol & spol.

>> 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žo­vá/červená níž), tak by žádné spešl nástroje nebyly potřeba.

Možná by web browser měl hlásit změnu "fingerprintu" stejně jako konzolový SSH ... děje se tak?

addons.mozilla.org má EV od VeriSignu – až nepůjde věřit tomuhle, tak budeme mít všichni úplně jiné problémy…

Vtip „případu Comodo“ je ale v tom, že certifikát na stejné jméno vydá i někdo jiný. Kdo asi tak ví, že addons.mozilla.org má mít EV od VeriSignu a při každém přístupu to kontroluje?

Vlada, ISP nebo kdokoliv 'in the middle' muze udelat MITM utok, aniz by potreboval (2) nebo (3), nebot si provoz proste presmeruje na routerech.

A (4) AFAIK prohlizece bezne nekontroluji (narozdil treba od SSH).

>> A (4) AFAIK prohlizece bezne nekontroluji (narozdil treba od SSH).

No tak pokud jsem paranoidní, tak používám takové prohlížeče nebo doplňky, které to kontrolují. Pak si může na MITM hrát kdo chce a je mu to platné jako mrtvýmu kabát.

2) nepotřebujete mít nic v lokální síti - stačí mít možnost mít něco někde po cestě:

http://en.wikipedia.org/wiki/Carnivore_%28software%29

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.

Zrovna u služeb Googlu se certifikáty mění dost často – vždycky mi to hlásí Certificate Patrol – ale jsou pokaždé od stejné CA.

"Vydupat" si klíč od vlastníka, který dbá na svoji bezpečnost není možné. Je-li správně uchováván, tak se k soukromému klíči dostat nelze a to ani pro provozovatele dané služby.

No právě...

ale muze podpsat certifikat "vladni" certifikacni autority a pro prohlizec to vyjde nastejno

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)

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...

Ano, tohle je pěkné svinstvo*, v takové firmě bych prostě nepracoval :-)

*) a reklamní materiály k takovým branám jsou pak pěkné počtení – k zblití

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.

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.

Ale to tvrdé odmítání je také princip PKI... Obdobně jako je v PKI důvěra v důvěryhodné certifikáty CA, tak je i nedůvěra v nedůvěryhodné certifikáty.

> 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.

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.

PKI se s tím vyrovnal revokací certifikátů. To, že je v některých prohlížečích práce s revokovanými certifikáty implementovaná špatně, není problém principu PKI.

>> 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/

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?

Nemůžete prohlašovat "PKI je nebezpečná jako celek", můžete prouze říci "Tato implementace PKI (Comodo) není bezpečná". To je celkem zásadní rozdíl...

Není to rozdíl, protože PKI jako celek je jenom tak bezpečná, jak je bezpečný její nejslabší článek (protože kterákoli CA může vydat certifikát k libovolnému jménu).

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ů.

IMHO není jiná možnost než značně omezit automatické důvěřování kde komu.

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.

_{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/global­trust), 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?

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?

Taky jsem na to neprisel jak, jen zminku ze ve verzi 3.0 to bude lepsi.. pokazde nemuzu odeslat email pres vstavaneho klienta (zrejme od HTC) - nezdarilo se odeslani. Po okamzitem prejdeni nastaveni stylem next/next/next/next ok, duveruji - se email odesle :/

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é.

Tím se bezpečnost vůbec nezvýší. Možná že to někoho bude hřát u srdce, že zabije spoustu času štelováním práv u certifikátů, ale jinak je to v praxi k ničemu.

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.

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).

Firefox: jednou se to naklika v Preferences->Advanced->View certificates, pak staci ostatnim uzivatelum skopirovat cert8.db (~/.mozilla/fi­refox/_profile­name_.default/cer­t8.db) do jejich profilu. Globalne to AFAIK nejde. Skopirovanim/prep­sanim 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)

Děkuji za ten Android. Již jsem si svoji CA přihodil (ještě zvážím zda nevyhodím ty ostatní-:).

U Firefoxu nutnost řešit CA jen v uživatelských profilech není dobrá věc...

A bez jedine zminky o OCSP? Smutne.

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.html

Jak 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.

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ři­pojení) 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.

Vidím, že nikdo nereaguje. Zkusme to tedy jinak.

Potřebuji doporučit nějaké weby se kterým bych zaručeně navázal šifrovanou komunikaci se sílou:

- 40 bitů
- 160 bitů
- 256 bitů

Díky za tipy. Uveďte vždy prosím k danému webu i sílu šifry, nejlépe i protokol včetně verze.

Zkuste si to otestovat proti Apačovi - modul SSL umí nastavit množinu šifer, kterou bude ochoten navázat spojení a název aktuální šifry pak ukládá od proměnných prostředí CGI.

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/pot­vrzení.
Budu s IE, ohledně této volby ještě experimentovat, ale nemohu hned.

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ášť.

>> 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

Tak tak...

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/

Tak to je hustý...

:((

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... :(

http://img135.imageshack.us/i/startcom.gif/

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.googled­nstest.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/Cer­tificate Patrol má momentálně "drobný problém" se servery, které "točí certifikáty často", např. encrypted.goo­gle.com nebo online.citiban­k.com:

https://imgur.com/a/vXoRt

(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ě.

Napište mi kdyžtak mail...

Všichni věříme jemu, on věří mě

komu čemu? MNĚ :/

a jeden dokonce pres mesic prosly - jak to dopadne, muset je menit casteji?
Co muzu delat, kdyz si ho chci overit? Vydany Esetem.

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 :).

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.