RFC 8484 (DNS přes HTTPS)

Bylo vydáno RFC 8484 řešící posílání DNS dotazů a získávání DNS odpovědí přes protokol HTTPS (DoH, DNS over HTTPS). V aktuálních verzích Firefoxu je DoH ve výchozím nastavení zakázáno. Povolit jej lze v about:config změnou hodnoty network.trr.mode (Trusted Recursive Resolver). V srpnu zveřejnila Mozilla výsledky experimentu s DNS přes HTTPS ve Firefoxu Nightly.

21.10.2018 01:00 | Ladislav Hagara | IT novinky

Komentáře

[Peter Golis]

Ďalšia užitočná konkurencia DNSSEC, ktorá povolí cenzúru?

[futurolog]

Obchadzanie anonymnych DNSiek ...

[Peter Golis]

Myslíš tých anonymných DNSiek u poskytovateľov internetu ktoré majú za úlohu on the fly upravovať odpovede? K tomu stačí pre to nové DNS over HTTPS aby bola odpoveď podpísaná od národnej autority, a cenzúra je zlegalizovaná a zneviditeľná.

[futurolog]

Nie, myslim anonymné DNSka [1] [2]...

[Peter Golis]

Tak zrovna tie majú rovnaký popis ako 8.8.8.8 alebo 1.1.1.1.

[snajpa]

Hm, za chvili poslou i TCP/IP pres HTTPS a pak se zatocime v takovym kruhu, ze se mi uz ted mota hlava. Jsem sam, komu tohle vymejsleni lidi od browseru pripada cim dal vic padly na hlavu? A teda nejen lidi od browseru, Mozilla, ta politicky korektni organizace hrajici vic nez prorezimni hru... Jeste jsou tu mnohem horsi Do No Evil (tm) Googlisti s Chrome a Gmailem a pocitem, ze jim do musli k snidani jako firemni benefit pridavaji namlete Salamounovo h... Meh. Ono se s tim dost blbe neco dela, ono se totiz rekne, ze IETF apod. procesy jsou verejne, mas se zapojit... Ale ma clovek realne sanci se pridat k lidem, kteri jsou od techhle Velkych Brasku zaplaceni na fulltime vc. proplacenych letenek a hotelu do tech nejlevnejsich destinaci na svete, kde se ty standardy tvori... Pripominkovaci proces mailem ovlivni tak prd, kdyz je polozena otazka i nasledna debata od zakladu spatne. Why the fuck would anyone need DNS over HTTPS? Why....

[smazáno]

Vzdyt WebSocket mame uz dlouho :).

[Michal Kubeček]

Jeste jsou tu mnohem horsi Do No Evil (tm) Googlisti s Chrome a Gmailem

Google na to jde trochu jinak, ten pro změnu snaží všechny stávající mechanismy obejít a tlačí QUIC.

[snajpa]

Jo, no. Nebo AMP... chtelo by to nejakym decentralizovanym search enginem, kterej se lidem bude chtit nechat zapnutej, Google zirelevantnit, jsou velmi zly sluha, ale jeste horsi pan...

[Bystroushaak]

Related: https://searx.me/, http://yacy.net/en/index.html.

[Bubak]

Aha, tak nejsem sam, koho po precteni prvni napadlo "Proc???"

[Michal Kubeček]

Což o to, na to je odpověď celkem jasná. Umožní to schovat DNS dotazy před někým, do by jejich sledováním mohl vidět, po jakých webech browsíte, a podvržením vás nasměrovat někam jinam, ať už je to ISP, zaměstnavatel, strýček Sam, strýček Voloďa, strýček Andrej nebo kdokoli jiný. Je tam samozřejmě řada technických otázek, které už jsou méně jasné. A pak také jedna filosofická otázka, zda (ne)důvěřujete víc svému ISP nebo firmě dodávající váš prohlížeč. :-)

[snajpa]

DNS over TLS?

[Michal Kubeček]

Netvrdil jsem, že je to dobré řešení nebo dokonce nejlepší řešení. Jen jsem odpovídal na otázku "proč".

[snajpa]

Jasne, a ja se ptam prave, proc, kdyz mame toto ^? Furt mi to nedopina, ten posledni odstavec v Introduction ctu jako “o TLS jsme nevedeli a tady mate druhou zastupnou trapnou vymluvu, everything over HTTPS, welcome to the future”. Proc by jako browser nemohl prosim pekne poskytovat API k systemovym zpusobum, jak se ptat DNS serveru? Na mne to uplne pusobi tak, ze tyhle veci teda uz moc nestranne vyvijeny nejsou, ze to korporatni prachy prevalcovaly a vlastne uz neni moc cesty zpet, jedine zase cele toto pekne HTTPS vc. Googlu a Mozilly znepotrebnit z uplne noveho vektoru, co zas vrati “power to the people”, na chvili.

[trekker.dk]

Podle mě je cílem Google hlavně to, aby se na HTTPS nedalo a nesmělo sáhnout, protože pak budou moci všude protlačit svoje služby, i když o ně nikdo nebude mít zájem. Ale nic nenaděláš, EU schvaluje nařízení, které jim dá monopol (protože filtrování copyrightovaného obsahu nikdo jiný neumí), občasná pokutička vylepší unijní rozpočet, všichni na tom vydělají. Teda pokud zrovna nejsi běžný jarda admin, který by si chtěl hrát na svém písečku a nepracovat pro megakorporát

[futurolog]

Dnes uz ludia nedoveruju najblizsim, neviem preco by mali doverovat ISP ci firme dodavajucej prehliadac...

[Michal Kubeček]

No a jakmile člověk překročí třicítku, měl by přestat věřit i sobě. :-) (Vida, a já si celou dobu myslel, že to pochází od Lennona.)

[Jendа]

Chtěl jsem napsat, že v Little Brother bylo dokonce 25, ale grepování odhalilo, že to tam důsledně používají s faktoriálem (Don't trust anyone over 25!).

[Bedňa]

Heh

[ʚĭɞ 🍉]

tak si myslím, že je čas křičet
nevěřte nikomu, komu je přes deset

Visací Zámek

[Bedňa]

Tak to je len parafráza na Johna Lennona, ktorý to zas prebral od nejakého fylozofa a ten asi ... tak nejak tu už všetko bolo len v inej farbe

[Max]

Já v tom vidím jeden bonus, né šifrování dns, na to máme tls, ale kompletní skrytí dns komunikace do http protokolu, aby nebyl tento provoz rozpoznavatelný / blokovatelný.
Zdar Max

[snajpa]

Jjjjjj, takze shodime rovnou tcp 443 a vyreseno, z moderniho Internetu a sluzeb, co by od nej clovek chtel, se najednou nedostane nikam, bo i kdyz treba pouziva email, stejne potrebuje web UI appku... (situace bezneho usera). Fakt nevidim problem v tom, ze mam odchozi traffic na sifrovane DNS, kdyz chodim na web. Asi to potrebuju poresolvovat, ne? ;) K cemu je uzitecna samotna informace, ze pouzivam DNS, kdyz je to vcelku logicke, ze ho potrebuju? Stejne jsou videt cilove IP, kterych se ptam i pri HTTPS... Vyhledove taky konec protunelovani si konektivity DNS dotazama na letistich apod., meh...

[Max]

Nejen webmail, ale i samotný mail jede přes https, viz třeba ActiveSync, nebo KerioConnect a spousta dalších věcí.
Zdar Max

[Radek]

A nedej bože když přes to jede proxy :D

[Stanislav Petr]

Cau, vis dobre ze okolo DNS se pohybuju celkem hodne, takze si dovolim taky par pripominek:

1. Jsem soucasti "te hrozne konspirace IETF" ale konference a hotely mi neplati zadnej velkej bratr (jestli na nejakyho mas kontakt prosim rekni mu ze shanim sponzora)

2. Pripominkovaci proces v ramci IETF jde ovlivnit emailem, ale souhlasim s stim ze jeden hlas tam nic moc neznamena, obzvlast kdyz za nim neni v IETF komunite dostatecne zname jmeno. V ramci IETF se standardizace provadi metodou "obece shody", tedy navrh je prijat pokud proti nemu dost nahlas nekrici opravdu hodne lidi - a to jak na meetingu tak na mailinglistech. Pokud se do toho chces zapojit je lepsi zacit napriklad prez nekterou z pracovnich skupin v ramci RIPE. V tomto pripade https://www.ripe.net/participate/ripe/wg/dns

3. Jak pises o kus dal - RFC8484 a RFC7858 (+RFC8310), idkyz to tak vypada nejsou duplicitni ale spise se doplnuji. RFC7858 resi obecne zabezpeceni prenosove cesty DNS, protoze DNS samo i pri pouzivani HTTPs odkryva cast informaci ktere je dobre nechat utajeny. Takze normalni DNS resolvery v ramci koncovych stanic by mely/mohly do budoucna prejit na DNS over TLS (napriklad se jiz pracuje na DHCP signalizaci ze dany rekurzivni server podporuje TLS). DNS over HTTPS je jen berlicka pro rekneme urcita zvlastni prostredi, coz vychazi z toho jak vypada paket podle RFC8484 a RFC7858 - v ramci DNS over HTTPS je z toho prece na prvni pohled videt ze to je mnohem mene efektivni ale na druhou stranu to resi nekolik jinych problemu, napriklad cely protokol je zvolen tak aby byl vyuzitelnu jednodiuse primo aplikacemi a to vcetne webovych aplikaci uvnitr prohlizece, schovani DNS provozu pred pripadnou lokalni chytristikou (urcite jsi uz zacil napriklad hotely s prilis aktivnim administratorem ktery zaviral na firewallu uplne vse a vynucujici napriklad jejich vlastni DNS rekurzory - tady ti DNS over HTTPS pomuze)

4. Ja napriklad ted pracuju na moznosti signalizace podpory TLS i pro autoritativni servery formou rozsireni predani NS zaznamu tak ze nadrazeny autoritativni server kdyz odkazuje na dalsi NS tak krome jeho nazvu preda i otisk jeho klice, takze DNS over TLS (resp. v tomto pripade spise DTLS) bude pouzitelne v ramci celeho DNS stromu...

5. Ke zpravicce, melo tam byt "V Breznu bylo vydani RFC 8484...." (zpravicka ma pul roku zpozdeni) :D

6. A jeste jak pises dal ze si ty rfc nejak konkurujou, tak citace z RFC 8484:

Acknowledgments

Thanks to the authors of both [RFC8094] and [RFC7858] for laying the groundwork for this document and for reviewing the contents. The authors would also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian Huitema, and John Levine for review and discussion of the ideas presented here.

[snajpa]

Ad bod jedna, ja jsem nerekl, ze je to konspirace IETF, to je spis o tech clenech a o jejich rozpoctech, ze. A potom o sekundarni slozitosti s komunitnim rozpoctem z Cech tyhle jejich seance nasledovat, je temer nemozny. Ty to mas vyreseny, kdyz hostujes miliony a miliony domen komercne, ze jo Nerikam, ze ty lokace vybira vedeni IETF, jestli vubec nejaky je - cekal bych, ze je to co nejtensi layer lidi, vsak fakt netvrdim, ze je tam konspirace - jenom tvrdim, ze to korporatni prachy "unesly" dal od vsech ostatnich, min privilegovanych - tj. i globalni akademie. Jak se treba profesori z UK/CVUT muzou do takovy veci zapojit? Kdo jim zaplati cestovny a hotely?

Ad bod tri, berlica pro ktera zvlastni prostredi? Browser nebezi v prostredi, kde bezi i standardni, rozvijejici se podporovany prostredi, ktery standardne podporuje resolvovani? Jakoze, proc to browsery musi resit jinak a vsechny ostatni aplikace na Internetu maji dal pouzivat normalni DNS standardy, ne nejaky sprsknutiny kone s veverkou?

Ad bod ctyri, myslis, ze by to slo bez toho, aby ses s tema lidma znal osobne uz?

Dik za obsahlou odpoved, i kdyz to trochu posvitilo na temny zakouti, furt v nich neni dost svetla, abych tam ten poklad, proc se tohle cely dela, nasel...

[Michal Kubeček]

Jak se treba profesori z UK/CVUT muzou do takovy veci zapojit? Kdo jim zaplati cestovny a hotely?

Teď zrovna bude v březnu meeting IETF v Praze. :-)

[Stanislav Petr]

Tak to muzeme jeste zjednodusit - pristi rok koncem brezna je IETF meeting tady v Praze (tradicne v Hiltnu v Praze - Karline). Myslim ze ti muzu zaridit sponzora co ti zaridi vstup, aby jsi nemusel platit konferencni poplatek a prohlednout si to primo "u zdroje"...

[snajpa]

No vidis. Hilton, ted zrovna naaahodou Praha, takze se nemusi resit ubytovani apod. Tuhle stredu odlitame se Sorkim na NixCon do Londyna, cela ta sranda vysla uz ted na raketu a to jsme jeste nikam nejeli (ubytko+letenky, pricem ty letenky jsou mnohem min kriticka cast) a to nepocitam, kolik propalime za takovou banalitu, jako nechcipnout tam hlady. Samotni organizatori jsou z toho smutni, ze je to ciste komunitni vec a vysla nakonec tak draho, ze nemuzou ani lidem slibit snidani, kterou puvodne meli v planu. Takze vlastne moje hlavni agenda, s cim tam pojedu, je pristi rok natahnout NixCon nekam k nam, idealne do Brna a spojit to s pristim Altem, napriklad... No a to je Londyn, to jsme jeste stale v Evrope. Jako fakt si budem hrat na to, ze se tady z tech sitaru a puvodne nerdsky komunity nestala rozmazlena smetanka preplacena zlatem? Vzdyt to je videt i u nas. Peering days jsou jaka naskrobena vec, pomalu s dress-code? :D Nevim no. To, ze zrovna ted nahodou nasinci nikam nemusi, neberu moc jako argument vuci globalnimu trendu (a ne trendu, ale uz v podstate danym stavu, kterej se nikomu nechce menit, viz tahle racionalizace - "vsak to bude v Praze, ted" - hm...)

[xxx]

V momente, kdy nechces konferenci poradat o vikendu a potrebujes 100+ lidi, tak to bohuzel skoncis nejspis vzdy v nejakem "luxusnim" resortu.

[Stanislav Petr]

Zrovna IETF byva v Praze pravidelne. A cestuje po velkych mestech po svete - a vzdycky to ma nekdo bliz a nekdo dal. Kdyz mame to tema DNS, tak dalsi konference ktera se toho tyka je ICANN meeting (ted byla Barcelona, coz je kousek a je levna). A taky putuji po velkych mestech po svete: https://meetings.icann.org/en/ (tam byl zrovna ted kolega). Akorat RIPE meeting uz v Praze nebude (byl pred par lety, ale RIPE ma takovy pravidlo ze nikde zatim nebyl velkej meeting dvakrat - s vyjimkou Amstru kde maj sidlo). A co se tyka navstevniku - tak na tehle akcich si ja jako predstavitel komercniho subjektu pripadam skoro utlacovanej mezi tou haldou akademiku...

Tak jak bude napriklad dalsi RIPE v Amstru tak pojed se mnou - nasledujici je Rejkiavik, to uznavam ze bude drahy (nicmene ten Amstr - cesta autem vyjde na par tisic, to je sranda... bydlet v konferencnim hotelu bejva drahy, ale ja vetsinou bydlim nekde kousek vedle vyrazne levnejc - napriklad v Amstru byva RIPE v hotelu Okura, ale 300 metru vedle v EasyHotelu uz bydlim za nejakejch 80 euro na noc...)

V kazdym pripade tyhle konference nejsou nijak nedostupny nebo extra drahy - clovek si pocka na levnejsi/blizsi misto kde se bude konat. No a kdyz uz se tam jednou s tema lidma seznamis, parkrat se opijete, tak uz se i v tech mailinglistech da debatovat ohledne standardizaci a rfc daleko lepe, kdyz ty lidi naproti sobe uz znas...

[snajpa]

Beru na vedomi, zaridim se. Cenny zkusenosti, dik, ze se podelis.

[Superklokan]

Cely ten humbuk okolo sifrovania je uplne smiesny. Na trhu su cenovo dostupne zariadenia a riesenia, pre ktore SSL trafika nerobi ziadny problem

https://www.a10networks.com/products/ssl-inspection

[lertimir]

No pokud sis to dobře přečetl, tak to na co odkazuješ je proxy. Takže ano, pokud budeš mít organizaci, která zakáže přímý provoz do internetu a všechny konekce musí jít přes proxy, tak máš pravdu. Na proxy bude vše vidět. Ale to není obecný případ.

[MadCatX]

A i přes takovouhle proxy lze protlačit šifrovaná data přes corkscrew. Stačí mít někde venku VPSku s běžícím SSHčkem.

[MadCatX]

(* Takto jednoduše by to šlo u HTTP proxy, u SOCKS proxy by to bylo složitější ale taky proveditelné.)

[Superklokan]

Neviem ako funguju ISP a domaci uzivatelia, ked ISP maju povinnost logovat trafiku a napr. blokovat pristup k domenam s hazardom. Nie je najjednoduhsie nasadit transparentnu proxy?

V pripade firiem a firemnych uzivatelov admini nasadzuju tiez proxyny na lepsiu kontrolu toku dat z/do internetu.

Kazdopadne nik sa nebude chvalit ze ma nasedenu technologiu na spehovanie svojich zakaznikov ci klientov, hoci ti ziju vo falosonm pocite bezpecia SSL.

Moc som tu technologiu od A10 nestudoval to bolo na ilustraciu a ze taka technologia je dostupna.

[MadCatX]

TLS se ve firmách apod. obchází tak, že na uživatelských strojích je nainstalován důvěryhodný certifikát vystavený tou firmou. HTTPS pak mezi uživatelem a firemní proxy běží šifrované tímto certifikátem, takže prohlížeč nic nehlásí a uživatel nic nepozná. Na proxy se to rozšifruje, vyfiltruje a cestou ven zašifruje znovu, tentokrát správným klíčem z certifikátu od serveru, se kterým komunikujeme. Tohle není nic nového a ta proxy od A10 pravděpodobně nic jiného nedělá.

Pokud si protistrany vymění klíče předem, jak je běžné třeba u SSH a šifrovaná data si předávají jako obsah skrz jinak nezabezpečený kanál - třeba HTTP - žádná proxy tomu nezabrání.

[Superklokan]

Dakujem za vysvetlenie. SSL nie je riesenie na utajenie komunikacie.

[Josef Kufner]

SSL je v pohodě, jen potřebuješ vědět, kdo je na druhé straně.

[smazáno]

Coz se soucasnym systemem duveryhodnych CA moc nejde a pokud chces pouzit self-signed cert tak to prohlizec povazuje za nejvetsi hrich.

[lertimir]

Opět to co již bylo řečeno. Musíš vědět, kdo je na druhé straně. znám paranoidní jedince, kteří z prohlížeče smazali celý systém kořenových autorit a z některých zařízení komunikují jen se selfsigned certificate systémy, jejichž certifikáty si sami nainstalovali do prohlížeče. A získali je nejdříve jiným komunikačním kanálem než přímým přihlášením k serveru.

[smazáno]

Stejne bezpecne by to mohlo fungovat pro vsechny a ne pouze pro paranoidni, kdyby byl zajem. Zajem je ale naopak aby to moc nefungovalo, pochopitelne.

[lertimir]

SSL (nebo spíše TLS od verze 1.2 výš) je řešení na utajení komunikace. Pořád se můžeš podívat kdo vydal ten certifikát a pro koho je vydaný. Ten certifikát vydaný firmou pro proxy musí být vydaný pro "*" jinak by to prohlížeč hlásil. A to samozřejmě poznáš. stačí si kliknout na certifikát a vidíš pro koho je vydaný. (A musím se ještě kouknout jak to certifikát akceptuje, protože nedávno jsme museli si nechat vydat LetEncrypt certifikát pro server.subdomena.firma.cz protože správně vydaný certifikát pro *.firma.cz sice funguje na všechny servery na 3 urovni ale ne na 4 úrovni. Takže obecný certifikát firmy, který bude fungovat na cokoliv mi úplně jasny není.) Takže ještě jednou TLS 1.2 a nové 1.3 je spolehlivé a bezpečné a v současnosti se neví žádná technika, jak je prolomit.

[Filip Jirsák]

Ty MitM proxy nemají jeden univerzální certifikát na všechno (on by takový certifikát vydaný na „*“ ani nefungoval), ale generují certifikáty vždy pro požadovanou adresu. Takže když půjdete na https://www.abclinuxu.cz, vygeneruje si ta proxy certifikát pro www.abclinuxu.cz, podepíše ho svou vlastní autoritou a ten certifikát pošle prohlížeči. Prohlížeč má mezi důvěryhodnými autoritami tu autoritu, kterou používá ten MitM proxy server, takže tomu certifikátu bude důvěřovat.

[MadCatX]

Na to jsi přišel jak? Ani ta MITM proxy TLS nelouskne, pokud na svém zařízení výslovně nepovolíš, že certifikáty vystavené tou proxy považuješ za důvěryhodné.

[Petr]

Není nutné aby to fungovalo jako proxy, může to být vůči provozu transparentní viz https://www.symantec.com/products/ssl-visibility-appliance Nic to nemění na tom, že koncové zařízení musí důvěřovat použité CA, která uvnitř vystavuje zástupné certifikáty.

[Petr]

Trochu tady mícháte jablka s hruškami. SSL intercepce bude fungovat jen pro prohlížeče/systémy pod kontrolou daného administrátora (společnosti), jelikož musí použitou CA dostat do důvěryhodných autorit daného systému/prohlížeče. Všem ostatním budou na všech webech vyskakovat varování před nedůvěryhodným certifikátem. Použití pro ISP nebo někoho pro odposlouchávání provozu je bez ovládnutí zdrojového počítače nemožné