Jak přesně tahle sranda s DNS zvýší bezpečnost? Pokud jsem schopný udělat MITM na HTTPS, proč bych neměl být schopný současně provést i MITM na DNS?
Jediná situace, při které by to teoreticky mohlo pomoct je MITM útok "blízko serveru" (takže útočník nemůže kontrolovat traffic klienta) s tím, že útočník zároveň nemůže kontrolovat autoritativní server pro danou doménu.
Takze ak to chapem dobre, len prehadzujeme zodpovednost z ruk CA do ruk spravcov narodnych domen? To je sice trochu lepsie, ale stale nie idealne... V pripade bananovych republik je riziko rovnake ako pri terajsich CA - teda ze za peniaze podpisu nieco co by nemali (o cenzure ani nehovorim), a v pripade pokrocilych demoktarickych statov zase hrozi (len :D ) cenzura. Su decentralizovane systemy ala namecoin naozaj tak ozrutne nepouzitelne ze by sa nemohli nasadit globalne po dohode kompetentnych?
Ano, jsou. Pěkně se na to téma rozepsal Paul Wouters: https://nohats.ca/wordpress/blog/2012/04/09/you-cant-p2p-the-dns-and-have-it-too/
Mít zabezpečenou cestu k validujícímu resolveru je základní bezpečnostní požadavek DNSSECu. DANE ke své činnosti potřebuje DNSSEC (to je v článku zmíněno), takže má i stejné požadavky. Pokud bychom měli v každém nadstavbovém protokolu vyjmenovat všechny požadavky nižších vrstev, za chvíli by se psalo o tom, že k DANE je třeba mít síť kořenových DNS serverů se známými adresami a že hostiteli musí fungovat UDP a TCP protokoly se všemi jejich požadavky.
To vážně necítíte rozdíl mezi bezpečnostními požadavky a obecnými požadavky typu funkční UDP a TCP? Kde jinde by se měly velmi důkladně probrat _všechny_ bezpečnostní požadavky než u analýzy protokolu který má ambice nahradit dnes majoritně používané bezpečnostní řešení (PKI)?
Jak moc si myslíte že je reálné uživatelům dávat (a udržovat aktuální) na jejich počítače DNSSEC-validating resolvery? Není to náhodou blocker který znemožňuje použití DNS (byť zabezpečeného pomocí DNSSEC) pro ukládání podkladů pro jakékoliv zabezpečení end-to-end komunikace (jako je například TLS)?
K druhému odstavci: Reálné to je, už nějakou dobu vzniká v NL.net Labs nástroj DNSSEC Trigger, který přesně k tomuto účelu slouží.
Dokonce pracují na tom, aby bylo možné zmiňovaný software zabudovávat do domácích routerů, kde se počítá s tím, že takový router obvykle nemá žádného správce. Viz prezentaci z letošního setkání ICANN.
Mně spíš připadá že to reálné moc není, protože by to mohlo vést k přetížení root nameserverů. Kouknul jsem na odkaz DNSSEC Trigger, a tam se s tím "vypořádávají" vskutku šalamounsky: "This unbound DNS server performs DNSSEC validation, but dnssec-trigger will signal it to to use the DHCP obtained forwarders if possible, and fallback to doing its own AUTH queries if that fails, and if that fails prompt the user via dnssec-trigger-applet the option to go with insecure DNS only." - takže preferované je nezabezpečené spojení na "DHCP obtained forwarders"? WTF? Zase pouhý pocit sucha a bezpečí bez reálného podkladu?
Přesně tak, DNSSEC Trigger je přesně ten software, který umožňuje používat DNSSEC validaci na koncovém PC a nezbláznit se z toho.
V základním stavu se dotazy směrují na DNS servery získané z DHCP. Pokud tyto servery nejsou použitelné, vyzkouší se přímo kořenové. Pokud ani ty nefungují, zkusí se použít tunelování portem tcp/80 a tcp/ssl/443. A pokud ani to nefunguje, je nabídnut hotspot-login mód, kdy se na několik minut validace vypne, aby bylo možné dostat se na captive portál a přihlásit se ručně.
Nemyslím si, že by byl problém, aby takovýto program byl distribuován spolu s internetovými prohlížeči, podobně jako Flash, nebo JRE. Jen je ještě chvilku počkat, než bude většina DNS resolverů schopna DNSSEC data nepoškozovat.
Ad "protokolu který má ambice nahradit dnes majoritně používané bezpečnostní řešení (PKI)?"
Docela důležitá otázka - zajímalo by mne, jestli takové ambice má (resp. jeho tvůrci a zastánci mají). Osobně ho beru jako doplněk, jeden z mnoha faktorů, který může doložit nebo naopak zpochybnit důvěryhodnost spojení, varovat před útokem nebo naopak zvýšit jistotu. Pak ho shledávám užitečným. Ale pokud by to měla být náhrada PKI, tak je to opravdu tragické.
Ad "Jak moc si myslíte že je reálné uživatelům dávat (a udržovat aktuální) na jejich počítače DNSSEC-validating resolvery?"
To uvidíme brzy - jistě nějakého "ISP" napadne, že by potřeboval podvrhávat DNSSEC záznamy - třeba kvůli zobrazování reklam, zpoplatnění přístupu na web, přesměrování uživatelů www prohlížečů, filtrování resp. cenzuře atd. - a ten pak uživatelům podstrčí nějaké resolvery, které buď nic neověřují nebo podvrhávají a podepisují úplně všechno a mají vlastní hierarchii klíčů...
U certifikátů (PKI) se uživatel aspoň může na podrobnosti, zjistit si hierarchii CA, otisky klíčů... existuje na to GUI, existují znalosti alespoň u části uživatelů. DNSSEC je v tomto dost pozadu.
„Docela důležitá otázka - zajímalo by mne, jestli takové ambice má (resp. jeho tvůrci a zastánci mají). Osobně ho beru jako doplněk, jeden z mnoha faktorů, který může doložit nebo naopak zpochybnit důvěryhodnost spojení, varovat před útokem nebo naopak zvýšit jistotu. Pak ho shledávám užitečným. Ale pokud by to měla být náhrada PKI, tak je to opravdu tragické.“
Jakožto hodně umírněný zastánce DNSSEC můžu potvrdit, že nahrazování PKI je pitomost, jelikož DNSSEC z velké části na PKI stojí a staví.
„a ten pak uživatelům podstrčí nějaké resolvery, které buď nic neověřují nebo podvrhávají a podepisují úplně všechno a mají vlastní hierarchii klíčů...“
Ale to bude moci podstrkovat jenom užiatelům, kteří:
a) používají jím dodávaný počítač
b) nevalidující počítač a jimi dodávaný validující router
c) nevalidující počítač a nevalidující router
Přičemž (c) je aktuální stav bez DNSSEC a (b) je příklad špatného nasazení DNSSEC. Na jednu stranu, nemůžu uvlivnit, jak bude většinově nasazován DNSSEC. Na druhou stranu, můžu to ovlivnit tam, kde jsem nějakým způsobem aktivní, t.j. například ve Fedoře. To stené platí pro mnohé z vás.
„Málokdo si DNSSEC validující nameserver spustí přímo na svém počítači, naopak - téměř všichni s ním komunikují po síti.“
Já teda rozhodně nemám v plánu používat validující nameserver po síti. Ve Fedoře se už delší dobu snažíme smysluplně integrovat validující nameserver. Celkem se nám daří, ale ještě to bude stát dost práce.
Nějak jsem nepochopil, jak se novým protokolem odstraní, v mých očích, pět současných problémů:
- Pravidla CA nejsou jednoduchá, nejsou většinou známá ani není tato informace dostupná, pravidla se nedodržují
- CA si vydávájí certifikáty jak je napadne (vlastně jde o nedodržování pravidel), dokonce umožňují různým skupinám a individuím tvorbu libovolného validního certifikátu
- Problém s neznámými a těžko odhadnutelnými certifikáty mezi certifikovaným "koncem" a CA
- Problém vystavitel/vystaveno pro/popisný název/... Většina validátorů ukazuje, ve většině případů, jen popisný název shodný tak často až to není pěkné, například USERTrust.
Zkuste schválně "ověřit" https://tails.boum.org/
- Problém s implementací šifrování u moderních browserů. Minimum informací a kontrola, módů se lze často dopátrat jen pomocí SSL-lab a testů.
Jediné čemu lze věřit je signatura/miniatura/hash certifikátu předaná vám důvěryhodným jedincem. Pak stačí jen doufat že nebyl odcizen, nepodařilo se ho vygenerovat, neselhala kontrola celistvosti. Takže, klidně lze zůstat u selfsigned certifikátů, akorát je třeba nezapomínat o nich informovat, odvolávat je...
Líbilo se mi nouzové řešení ESETu, kdy veškeré certifikáty které jste chtěly uznat musely být podepsány jejich certifikátem, jinak je antivirus vyhodnnotil jako nedůvěryhodné a podvržené. O tom, že sami si neumí hlídat ani platnost svého certifikátu se ale lépe nezmiňovat. Nicméně takhle nějak by to mohlo fungovat v systému. Neznám - položím dotaz na schválený účel, zatřídím, podepíši (schválím). Toto řešení je pochopitelně jen berlička, nad jinou nefungující berličkou (teď mluvím o úložišti, jeho správě a funkci), která by přitom mohla fungovat, kdyby to někdo totálně a úplně zbytečně nepos.. -píp-
> Jediné čemu lze věřit je signatura/miniatura/hash certifikátu předaná vám důvěryhodným jedincem. Pak stačí jen doufat že nebyl odcizen, nepodařilo se ho vygenerovat, neselhala kontrola celistvosti. Takže, klidně lze zůstat u selfsigned certifikátů, akorát je třeba nezapomínat o nich informovat, odvolávat je...
No, a tady je otázka, zda-li pro vás je úroveň důvěry ve strom DNS zabezpečený pomocí DNSSEC je dostatečná nebo ne. Tedy jestli je tento způsob předání dostatečně blízko vaší definici 'důvěryhodného jedince'. Pokud ano, tak self-signed certifikáty jsou definovány v cert.usage 2/3. Pro mě je třeba posun směrem blíž k držiteli/vlastníkovi domény, který ví, jaký certifikát se má použít, je zásadní vylepšení. A cert.usage 0/1 beru jako takovou úlitbu certifikačním bohům (tedy ještě pořád osobně považuju EV certifikáty za vcelku užitečně, ale s tím rozdílem, že je to něco, co by CA měly dělat jako nejnižší úroveň zabezpečení).
> - Pravidla CA nejsou jednoduchá, nejsou většinou známá ani není tato informace dostupná, pravidla se nedodržují
Jenom taková perlička - v průběhu diskuze vyplynulo, že CA mají jakési listy "důležitých" domén, pro které vám nevystaví automaticky certifikát jen klikáním na webu (DV cert). Jak se dostat na takový seznam je ovšem už záhadou - aneb osobně je mi jedno jestli je chráněná bofa.com, ale víc mě bude tak nějak trápit např. fio.cz.
??? Jaké DNSSEC ? Myslím, že jsem pochopil původního autora a sám mám podobný přístup. Zajímá mě asi 5 domén, u kterých chci mít jistotu, že se bavím se správným serverem. Na CA spoléhat nelze, takže mě zajímá hash certifikátu. Moje banka např. hash uvádí na svém webu. Optimální by bylo, kdybych ho dostal třeba poštou doporučeně, ale to by bylo administrativně náročné. Takže vezmu TOR a prohlédnu si web své banky z Ruska, z USA a třeba z Nigérie. Uvidím-li stejný hash ze všech států, je pravděpodobné, že MITM může být jen někde hodně blízko serveru banky. Kdybych chtěl být extra paranoidní, počkám 2 týdny a proceduru zopakuji a budu očekávat stejný hash. Pak tedy konečně vlezu na server své banky, zkontroluji si hash a odkliknu certifikát jako platný. Předtím jsem samozřejmě smazal úplně všechny "důvěruhodné" certifikační autority. S tímto si vystačím po následující 2 roky, než se certifikát změní (vyprší mu platnost). DNS a DNSSEC je mi v tuto chvíli šumák, klidně mohu dostat podvrženou IP. Nedostanu ovšem už certifikát se stejným hashem, jako jsem si uložil. Pokud ano, tak se hacker vloupal do banky a v tom mi žádná CA nepomůže.
Ano, snaha udělat pořádek v CA je chvályhodná, nicméně to bude IMO nejméně 5 let trvat a já potřebuji bezpečně pracovat už teď. Tedy zůstávám u své metody - smazání všech CA a zadání výjimek jen pro servery, které mě zajímají. Ostatní - například podvržený google - je mi fuk. Přesněji - na to mi stačí ty "důvěryhodné" CA - je to nedůležité.
Petr
Nicméně takhle nějak by to mohlo fungovat v systému. Neznám - položím dotaz na schválený účel, zatřídím, podepíši (schválím).
Nějak takto to funguje u Windows Internet Exploreru. Ten (a s ním celý OS Windows) důvěřuje po instalaci pouze několika CA. Když uvidí novou, dosud neznámou autoritu, nejprve se v tichosti zeptá u Microsoftu, jestli této nové CA může důvěřovat. Pokud strýček Bill řekne, že ano, CA se v tichosti přidá mezi důvěryhodné a uživatel nic nepozná.
Vzhledem k tomu, že DNSSEC mají na světě všichni v paži, tak tím padá i tato relativně zajimavá myšlenka. To že u nás, díky aktivitám CZNICu, má podepsanou zónu relativně hodně domén je v celosvětovém měřítku celkem k ničemu. I u nás rekurzivní resolver člověk stejně najde tak maximálně u sebe doma.
Takže hezká práce, ale obávám se, že spíše do šuplíku...
Chlapi, dobrá práce. Věřím, že certifikačním autoritám to po chuti moc nebude a určitě se budou zavedení bránit, držím pěsti. Když už jste u toho "vylepšování internetů", nemohli byste nějakým způsobem i trochu popíchnout vývojáře prohlížečů, aby začali podporovat OCSP stapling, bez ztráty kytičky to zatím zvládá jen Opera (alespoň podle mého, lehce dnssec.cz inspirovaného, "ocsp stapling testu")? :-) Mnoho OCSP serverů ve špičce vůbec neodpoví, stapling by určitě pomohl zvláště menším CA.