@MightyPork píše, že ani OpenDNS nejede. Doporučuji použít DNS od svého ISP (pokud je máte někde poznačené, já je měl jen v poště na @gmail.com :-D)
Upřimně bych radu použít OpenDNS, které nepodporuje DNSSEC (narozdíl od Google PDNS), tady nečekal. Pokud opravdu máte potřebu sdílet svá DNS data se třetí stranou, tak bych z těch větších raději použil Verisign Public DNS (https://www.verisign.com/en_US/security-services/public-dns/index.xhtml).
Ale upřimně je nejjednodušší[*] si na localhostu nahodil vlastní validující DNS resolver.
* - pokud zrovna nejste na hotelové taky-"wifi"
Úplně nulovou pravděpodobnost garantuje jen odpojení od sítě (což z druhé strany může být bráno jako úspěšný útok DoS), ale limitně nulovou třeba správně implementovaná kryptografie na přenosové vrstvě (např. TLS) která stejně je potřeba i pokud by perfektně fungovalo DNSSSEC.
Proti otrávení cache rekurzivního serveru existují mnohem jednodušší obrany než DNSSEC, to je v tomto případě kanón na vrabce.
A rozhodně nesouhlasím s vaší poslední větou - pokud se některý ze serverů po cestě rozhodně implementovat DNSSEC tak je přeci mnohem jednodušší mu přetížit CPU! Z tohoto důvodu považuji všechny otevřené resolvery které podporují DNSSEC za nespolehlivé, stačí jim poslat dostatek dotazů na domény zabezpečené DNSSEC (klidně pomocí UDP paketů s podvrženými zdrojovými adresami) a koukat co to s nimi udělá...
Proti otrávení cache rekurzivního serveru existují mnohem jednodušší obrany než DNSSEC, to je v tomto případě kanón na vrabce.
Zřejmě víte něco víc než my ostatní, dokonce i víc než Dan Kaminsky. Tak se podělte s námi.
Z tohoto důvodu považuji všechny otevřené resolvery které podporují DNSSEC za nespolehlivé, stačí jim poslat dostatek dotazů na domény zabezpečené DNSSEC (klidně pomocí UDP paketů s podvrženými zdrojovými adresami) a koukat co to s nimi udělá...
Zkuste to někdy a vraťte se zpátky, až se vám něco takového povede.
V době kdy Dan Kaminsky publikoval svůj objev tak tento útok skutečně fungoval, ale zveřejnění způsobilo vyvinutí jednoduché obrany spočívající v randomizaci zdrojových portů UDP paketů a ignorování přibalených informací o nameserverech (které jsou v rozporu s tím co už je v cache) v odpovědích, což snižuje pravděpodobnost úspěchu tohoto útoku prakticky na nulu.
To jsou zase moudrosti.
Denodenně děláte kompromisy ohledně bezpečnosti v reálném životě, ale pro IT žádné kompromisy neplatí.
Pokud to myslíte doopravdy, navrhuji nechat přístě vchodové dveře dokořán otevřené, na co kompromisy, žádný zámek neodolá a i sebelepší zabezpečení dveří lze překonat. Jsem zvědav, jak dlouho na ten "falešný" pocit bezpečí ještě dáte....
Jenom takovy provokativni napad, kdyz uz je to problem routovani:
- neni duvodem nahodou 'masivni' nasazeni nejakeho noveho modelu routeru? ( https://omnia.turris.cz/cs/ )
:-D
(ja vim, blbost - ale ne odlehceni)
Jenže k tomu zabezpečení pomocí TLS si nějak věrohodně potřebujete ověřit, že protistrana opravdu patří k uvedené doméně. A k tomu opět potřebujete nějak věrohodně získat údaje z DNS – tedy potřebujete DNSSEC. (To, že nějaká certifikační autorita získá nepodepsanou DNS odpověď a pak se pod to podepíše, nepovažuju za dostatečně věrohodné.)
K dostudování: obsah X.509 certifikátu který je podepsaný důvěryhodnou certifikační autoritou.
Nastudujte si, jak ta certifikační autorita zjistí, že majitel privátního klíče, k jehož veřejnému klíči chce vystavit certifikát, je opravdu držitelem domény, kterou chce v tom certifikátu uvést. A pak si zkuste ten můj komentář dočíst až do konce. I s tou poslední větou, v závorce. Trochu smutné, že jsem váš komentář vyvrátil dřív, než jste ho napsal, nemyslíte?
Já jsem nikdy netvrdil, že se v certifikátu musí ověřovat jenom jméno DNS. Ale bavíme se tu o certifikátech jako způsobu, jak ověřit, že komunikuju opravdu se serverem pro nějaké doménové jméno. Co byste chtěl na takovém certifikátu jiného, než doménové jméno? Tváříte se jak mistr světa, ale nenapsal jste nic konkrétního a jenom jste začal kličkovat.
Následují základy PKI pro Jirsáka, ostatním kteří toto běžně ovládají se omlouvám za popisování takové triviality: certifikační autorita ověří že uživatel je oprávněným uživatelem daného doménového jména (jak to CA musí dělat není konkrétně předepsáno, u různých CA se to liší od laciného ověření u startssl.com po důkladný audit u dražších CA) a toto potvrdí vydáním certifikátu se svým podpisem, takže každý server který se pak takovým certifikátem prokáže (t.j. při TLS handshake prokáže že má přístup k privátnímu klíči který odpovídá tomu veřejnému klíči který je v certifikátu) je pak možno považovat za oprávněně používající dané doménové jméno.
Vy se tady smolíte s odpovědí, kterou jsem já dávno předvídal, takže jsem už včera v 8:15 na tento váš komentář odpověděl. Akorát teda ten komentář musíte dočíst až do konce, včetně té závorky na konci. Už jsem vás na to jednou upozorňoval.
Mimochodem, psal jste, že v certifikátu nemusí být potvrzené jenom doménové jméno. A teď zase operujete s tím doménovým jménem. Tak co jste vlastně chtěl říct?
uživatel je oprávněným uživatelem daného doménového jména (jak to CA musí dělat není konkrétně předepsáno, u různých CA se to liší od laciného ověření u startssl.com po důkladný audit u dražších CA)
No a v tom je právě zakopaný pes. Ta certifikační autorita obecně nemá jinou možnost, jak ověřit doménové jméno, než právě přes DNS. Takže pokud nevěříte DNS, nemůžete věřit ani tomu certifikátu vydanému certifikační autoritou. Protože ta autorita může DNS ověřovat třeba z dvaceti různých sítí, může to dělat v s odstupem času, ale pořád to bude zjišťovat jen z DNS a nezíská z DNS spolehlivější informace, než jaké můžete získat vy (vy si ten DNS záznam také můžete ověřit z dvaceti různých sítí a s časovým odstupem). To je to, na co jsem upozorňoval hned v tom prvním komentáři v závorce, a co vy,který se stavíte do role velkého znalce PKI (ale zatím jste nic nepředvedl), nevidíte nebo vidět nechcete.
I pokud by nějaká CA měla nějaký nestandardní zabezpečený kanál k nějakému registrátorovi, není to obecné řešení. DNSSEC je obecné řešení, je to přesně takový zabezpečený kanál od registrátora, ale je veřejný a může ho použít každý. Pořád ale musí CA spoléhat na toho registrátora – protože to je on, kdo definuje, které doménové jméno komu patří. Tak je to definováno v DNS systému. Může se vám to nelíbit, pak ale nekritizujete DNSSEC, ale DNS jako takové.
Mimochodem, ten „důkladný audit“ nezávisí na tom, která autorita to dělá, ale o jaký se jedná certifikát. Pro DV certifikáty se žádný důkladný audit nedělá, protože tam není co auditovat – tam se autorita pokusí ověřit doménové jméno, pokud možno tak, aby nenaletěla těm nejprimitivnějším útokům na DNS, a tím to celé končí – není, co by na tom mohla ještě prověřovat. Mimochodem, DV certifikáty vystavují i ty dražší CA. Audit se dělá u OV certifikátů, důkladný audit u EV certifikátů – protože ty se vystavují na jména subjektů (osob, organizací). Takže tam musí CA ověřit, že žadatel opravdu jedná a má právo jednat za danou organizaci. A mimochodem, i StartCom vydává OV a EV certifikáty (ne že by bylo rozumné je od nich dnes kupovat).
"Ta certifikační autorita obecně nemá jinou možnost, jak ověřit doménové jméno, než právě přes DNS." - to prostě není pravda! To že jste se ještě nesetkal s CA která by prováděla zodpovědný audit který spočívá i v něčem jiném než jsou dotazy do DNS (jako např. certifikáty zdarma od startssl.com) neznamená že takové CA nejsou! Dokud si tento svůj neustále opakovaný omyl neuvědomíte nemá smysl v diskusi pokračovat.
Nechme stranou DV nebo neDV což je jenom marketingová záležitost různých CA která s obecným TLS nemá nic společného. Konkrétní příklad CA která vydává certifikáty na základě ověření které nespoléhá na dotazy do DNS (místo toho používají dotazy přímo k registrátorům) je třeba tady: http://www.ica.cz/Dokumenty-ziskani-serveroveho-certifikatu
Útočník si samozřejmě může nechat vystavit certifikát od jakékoliv CA, jde jen o to aby jí uživatelé věřili - tím se samozřejmě ukazuje že útok na uživatele kteří důvěřují pofidérním CA je jednodušší než útok na uživatele kteří důvěřují pouze zodpovědným CA, ale to je holt základ celého PKI s CA.
Nechme stranou DV nebo neDV
Takže opravdu nechápete, o čem je tady řeč. Celou dobu řešíme, jak zajistit, aby útočník nemohl podvržením DNS odpovědí způsobit, že se budu chtít připojit třeba k www.root.cz, ale místo toho se připojím k serveru útočníka.
Konkrétní příklad CA která vydává certifikáty na základě ověření které nespoléhá na dotazy do DNS (místo toho používají dotazy přímo k registrátorům)
Používají dotazy přímo k registrátorům? Opravdu? Tak jak budou ověřovat tu doménu dvucs.ff.cuni.cz? Kterého registrátora se budou dotazovat a jak? Myslíte si, že se takový Verisign bude bavit s nějakou I.CA? A myslíte si, že I.CA bude shánět registrátora třeba pro doménu .bt?
třeba tady: http://www.ica.cz/Dokumenty-ziskani-serveroveho-certifikatu
Smůla je, že jste se trefil zrovna do typu certifikátu, ve kterém doménové jméno vůbec není. Podle toho se bude doména ověřovat dost těžko, nemyslíte? Můžete se přesvědčit v certifikační politice pro vydávání technologických (komerčních serverových) certifikátů. Certifikáty s doménovým jménem I.CA nazývá „SSL certifikáty“ a pokud vím, momentálně je nevydává. Má pro ně připravenou certifikační politiku: Certifikační politika vydávání SSL certifikátů. Porovnejte si profily certifikátu v kapitolách 7 a pojmenování v kapitolách 3.1.
"Ta certifikační autorita obecně nemá jinou možnost, jak ověřit doménové jméno, než právě přes DNS." - to prostě není pravda!
Vzhledem k tomu, co jste zatím předvedl (spíš nepředvedl), bude potřeba, abyste své tvrzení doložil něčím jiným než vykřičníkem.
To že jste se ještě nesetkal s CA která by prováděla zodpovědný audit který spočívá i v něčem jiném než jsou dotazy do DNS […] neznamená že takové CA nejsou!
Já jsem se s takovými CA setkal. Ale nebylo to při vydávání DV certifikátů. Protože ono se s doménovým jménem opravdu nedá dělat nic jiného, než že přes DNS registrátora nadřazené domény zjistíte, zda dotyčný žadatel opravdu má s tou doménou něco společného.
Ale pokud chcete tvrdit, že nějaké CA při vydávání DV certifikátů něco ověřují ještě jiným způsobem než jsou dotazy do DNS, popište nám, jak taková autorita bude postupovat při vydávání DV certifikátu pro doménové jméno dvucs.ff.cuni.cz.
Dokud si tento svůj neustále opakovaný omyl neuvědomíte nemá smysl v diskusi pokračovat.
No, zatím jediný, kdo tu předvádí, že v tom má hokej, jste vy. Mám silné tušení, že si pletete, co jsou DV, OV a EV certifikáty.
...omlouvám se, ale nedá mi to a pořád musím myslet na to, jak asi vypadá ten ultimátní fix...
Tak ta představa ultimátního fixu nesmí být v žádném případě v blistru, nýbrž v kelímku, a to již dobrých 35 let. Ač totiž blistr obstojí při transportu v aktovce, zatímco kelínek ne (praská), ultimátní fix patří odnepaměti do kelímku.
Smutné však je, že jsem ten nejultimátnější kelímek s kalendářem nevygooglil, a co je ještě smutnější, selhal i Seznam. Tak jen novodobý odvar...
https://img1.sevt.cz/Files/_t_/Images/41806800_800_800_wm_fit.jpg