Názory k článku Mozilla má pravidla pro DNS-over-HTTPS a důvěryhodné resolvery

Mam to chapat tak ze to Mozilla hodla zapnout ve vychozim stavu a rovnou to smerovat na cloudflare? Takze to budeme muset vsude automaticky vypinat kvuli lokalnim DNS zaznamum(vnitrni vs vnejsi IP)?

Ano, hodlá to zapnout ve výchozím stavu. Jestli to bude směřovat na CF nebo jinam se zatím úplně neví.
Lokální záznamy nevadí, pokud nejsou zároveň resolvovatelné přes DoH – Firefox nejspíše ve výchozím stavu zkusí systémový resolver, když dotaz přes DoH selže*. Pokud ale vaše DNS infrastruktura vrací různá data pod stejnými doménovými jmény v závislosti na tom, odkud se kdo ptá, pak ano, pak budete mít problém.

*) Je ovšem ještě otázka, jestli se NXDOMAIN považuje za selhání nebo ne. Nejspíš ne.

Ovšem ten problém už máte teď, pokud si uživatel může nastavit vlastní DNS resolver. Pokud si tam teď dá čtyři osmičky, jste ve stejné situaci, pokud mu nebudete na síti nějak ošklivě unášet spojení. Jestliže máte stroje ve své správě (což ve firmě typicky máte), zajistíte si změnu konfigurace dle libosti s klasickým DNS i po nasazení DoH.

Jenze je rozdil systemovy DNS resolver a DNS resolver v nejake aplikaci. V beznych aplikacich ma uzivatel defacto pravo zmenit cokoli.

Tak se mu to rozbije. I teď si může v prohlížeči nastavit uživatelsky spoustu věcí, které mu to kompletně rozloží. Namátkou si třeba zapne použití proxy na nějakou náhodnou adresu a přestane mu „jít internet“. Tohle by ale uživatel dělat neměl, aby se mu věci nerozbily. A také to obvykle nedělá.

Jde o to ze vetsinou jsou to BFU nebo rozumni lide kterym vysvetlite ze si maji nechat nastaveny lokalni DNS resolver(typicky predany pres DHCP) jinak jim to nebude hlavne u mobilnich zarizeni fungovat. Typicky treba firemni cloud na noteboocich a mobilech.

Pro mi prave vadi ze toto obejde systemovy resolver, ktery je nastaveny spravne a v ten moment jim prestane fungovat treba webove rozhrani pri prepojeni mobilnich dat na lokalni wifi a naopak. Ze se to da vypnout je jasne, problem je vypinat to u vsech a vubec na to myslet to vypnout pri preinstalaci apod. Pak je dalsi problem aby se to nahodou nechovalo jako Widle a pri kazde aktualizaci si to zrovna toto nehodilo zpet do vychoziho nastaveni.

Osobne bych tedy uvital spise vychozi vypnuty stav a maximalne pobidnuti uzivatele k zapnuti ... to uz se da vsem vysvetlit aby to nezapinali. S technologii nebo implementaci problem nemam.

No, možná to skončí podobně jako u chrome - někde v temných hlubinách budou existovat policies, které může instalovat jen administrátor, a které umožní přenastavit security výrazně více, než může uživatel. Dokumentace k nim se bude shánět zase docela těžko, hlavně proto, že dokumentace nebude vybíhat při googlení konrétního problému. (Ty policies umožnovali do chrome instalovat vlastní javascript user scripty, jak je to teď ale netuším.)

Když si tam dá 8.8.8.8, může admin mít redirect na interní DNS. DNSSSEC stejně Windows stanice neřeší.

Takze to prakticky obejde systemovy resolver :/

I tohle chovani je uz samo o sobe problemove.

Za prve, veskere interni DNS requesty by sly ven (jo ja vim, ze telemetrie to casto kopne tak jako tak ven).
Za druhe, v pripade blokaci https provozu smerem ven se znasobi spam v logu firewallu/proxy.
Za treti, v pripade VPN se to bude chovat jeste neznamo jak.

Ne, FF rozhodne dlouhodobe nefunguje v souladu s potrebami firemni infrastruktury, naopak mnohdy jde proti firemnimpotrebam (dlouhodobe chybejici gpo, interni CA atd).

<no-flame>
Kdo by proboha blokoval HTTPS provoz ven? A proč?
</no-flame>

Na otazky proc je jednoducha odpoved. Protoze pres HTTPS lze prenaset libovolna data a neda se zjistit jaka. To je v pripade vyssi urovne zabezpeceni uniku dat z firmy problem. Takze se to resi bud zakazem HTTPS, nebo instalaci firemniho certifikatu, kdy se na MitM na firewalu/proxy prebaluje sifrovana komunikace pod jiny cert/autoritu.
Oboje je reseni nedokonale tak "trochu" rozbite, ale pouziva se bezne.

Já doufám, že by to mohlo přispět k tomu, že se vrátíme k používání jednoho globálního DNS stromu. Ty lokální DNS resolvery, které překládají adresy, které jinde přeložit nelze, nebo je překládají jinak, jsou zlo. (A samozřejmě je to jeden z důsledků nedostatku IPv4 adres.) Dnes má každý v kapse multihome zařízení, takže je lichá představa, že zařízení je připojené v jedné síti a její správce nad ním má plnou kontrolu. Snad se postupně vracíme k Internetu, který má fungovat jako hloupá transportní síť, která se stará jenom o to odkud kam má předat paket a nesnaží se vrtat ve věcech, do kterých jí nic není. A to se mi jinak trend internet-over-HTTPS nelíbí.

Upřesnil bych kouskem citace z toho odkázaného oznámení:
> In addition we may have DoH/TRR on by default in some regions and not others, especially initially.

Osobně to vidím jako plány a jelikož je to dost citlivé téma, řekl bych že je nejisté jak přesně se to nakonec vyvine. Pokud dobře pamatuji, z Chrome se vyjádřili že nechtějí by default obcházet politiku OS/sítě.

Je krasne, ze tam napsali o moznosti konfigurace na dalku. MDM? To, ze se tim konfiguruji aplikace na dalku, jsem netusil. Ani to ve firme nemame. A urcite to nepodporuje Linux. Jestli to defaultne zapnou, tak Firefox pujde z firmy ven.

Linux snad jde konfigurovat na dálku sám od sebe, ne? Stačí třeba ssh a poeditovat konfigurační soubor v profilu Firefoxu.

Myslím, že velmi dobře shrnul názor většiny DNS komunity Geoff Huston: https://www.potaroo.net/ispcol/2019-04/angst.html
V případě DoH se s vaničkou nevylilo jedno dítě ale rovnou celá mateřská škola.
Monitorovat IoS zařízení a malware v domácích podmínkách bude s DoH prakticky nemožné.

To není workaround. Smysl toho zákona je, aby se lidé na ty weby nedostali tak snadno, což ten DNS blacklist splňuje dobře. Donutit ISP k daleko dražšímu řešení pouhou změnou výkladu půjde těžko, takže je dost pravděpodobné, že to vyšumí do ztracena – vlk se nažral, a koza zůstala celá.

Třeba si státy jednou uvědomí, že pokud chtějí vynucovat dodržování zákonů na internetu, budou muset spolupracovat.

Znění paragrafu 82 sice je jasné, v tom není problém. Problém je v tom, že se spousta ajťáků se snaží binární logiku aplikovat (například) i na právo, které tak ale nefunguje. Nikdy nemůžete vytrhnout jeden paragraf zákona a zabývat se jenom jím. S vaším přístupem by měl ISP jedinou možnost – vytrhnout síťový kabel, aby zabránil jakémukoli přenosu. Protože i něco, co může vypadat jako naprosto neškodný přenos obrázku přes HTTP může být ve skutečnosti tunelovaná komunikace s těmi zakázanými weby. Jenže ve skutečnosti neplatí, že je potřeba dodržet § 82 za každou cenu a vše ostatní jde stranou. Ve skutečnosti platí i ostatní zákony, které je také potřeba dodržovat, a které tomuhle absolutnímu přístupu k § 82 naopak brání.

Existuje i jiná alternativa - stát donutí ISP zaříznout resolvery na TRR seznamu, pokud nebudou dodržovat pravidla platná pro danou zemi. Pak se teprve uvidí, jestli DNS silům jde o soukromí uživatelů nebo o jejich data...

Sice je to složitější, ale nakonec lze jakékoliv filtrování ojebat např. tunelem či VPN. Pak byste musel skončit u toho, že bude poskytovatel blokovat přístup k jakékoliv adrese či jakéhokoliv toku, u kterého není jasné, co obsahuje. Vím, že nejpokrokovější angličtí soudruzi k tomu mají dobře našlápnuto, ale dokud nebudou Češi poserové, nemusíme tu mít každou vymoženost Západu.

Pokud jsem metodiku dříve dobře četl, ISP má povinnost bránit v přístupu pouze pokud ten uživatel explicitně neudělá krok kterým ho obejde (například změna na X.X.X.X resolver). Bohužel, defaultní nastavení významného prohlížeče už bude jistě těžší považovat za explicitní obcházení a tady vidím jisté riziko jak bude stát reagovat.

Blokování dle IP adresy je v metodice explicitně vyloučeno, protože by mohlo zablokovat i něco mimo seznam. V tuto chvíli se SNI asi moc nešifruje, tak to by nějakou chvíli možná smyslu toho nařízení odpovídalo, i když by to pravděpodobně bylo pro ISP nákladnější. Ale co nastane potom?

Tenhle argument o boji proti malware prostřednictvím DNS upřímně moc nechápu. Pokud většina sítí propouští HTTPS a zároveň nějakým způsobem filtruje DNS, proč by se měl tvůrce malwaru snažit komunikovat skrytě pomocí DNS, když může komunikovat zcela otevřeně uvnitř šifrovaného HTTPS? Představa, že správnými zásahy do DNS provozu dokážu ochránit síť před malwarem mi připadá docela úsměvná.

Nehledě na to, že celý internet stojí na principu dumb core - smart edge. Tedy chytrost má být na koncovém zařízení, ne někde po cestě. Z toho pohledu se dá říct, že DoH vlastně vynucuje původní koncepci internetu, protože nikde jinde než na konci do provozu není možné zasahovat.

Po IETF 104 jsem to dlouze zkoumal a můj názor je, že v (některých) "enterprise sítích" mají chytré firewally které sledují DNS i HTTPS zároveň a (kromě jiného) blokují spojení na adresy které neprošly nedávno firemním DNS (které mají filtrované nějakými komerčními RPZ feedy). Možná je hned neblokují a jen logují jako podezřelé, nebo tak něco. Port 853 tedy mohou snadno blokovat, známé X.X.X.X adresy taky. Tihle lidé teď mají pocit, že to byl dobrý kompromis který už nebude z velké části fungovat a tedy budou nuceni k drastičtějším opatřením, třeba HTTPS zakázat a dovolit jen skrze MITM proxy.

Aby bylo jasno, není mým cílem se jich zastávat, jen pochopit jejich motivaci. Mimochodem, u nikoho z nich jsem přímým dotazem neověřoval jak moc jsem se s tou hypotézou trefil...

No, popravdě řečeno, kdo z nás adminů může říct, že má tak zabezpečeny browser, že mu stažením nějaké stránky a následným DNS rebindingem nezaútočí jeho vlastní browser na jím spravované počítače. Zrovna tady se hodí mít DNS firewall, a DNS rebindingu zamezit (resp. zamezit resolvení "externích" domén na "interní" adresy). Potom už alespoň bude mít útočník sníženou působnost díky same-origin-policy.

blokují spojení na adresy které neprošly nedávno firemním DNS
Jak by to mohlo fungovat, když platnost DNS záznamu je často jeden den a může být i delší? Po tu dobu může klient zcela legálně záznam kešovat a nemusí se na něj ptát znovu. Nebo je to postavené na nějaké empirické zkušenosti, mají to zaplé třeba jen pro stanice s Windows a vědí, že ty Windows nikdy nepoběží déle než den v kuse a žádná používaná aplikace nekešuje záznamy na disk, aby mohly přežít restart?

Tihle lidé teď mají pocit, že to byl dobrý kompromis který už nebude z velké části fungovat a tedy budou nuceni k drastičtějším opatřením, třeba HTTPS zakázat a dovolit jen skrze MITM proxy.
Chtělo by to nějakou osvětu, že dělat díry do zabezpečení není dobrý způsob, jak zvyšovat bezpečnost. Já chápu, že je lákavá představa, že se bezpečnost vyřeší tak, že se všechna komunikace svede do jedné velké černé krabice, na které budou nepravidelně blikat dvě různě barevné LEDky, ale tak to na internetu nikdy fungovat nebude. Spíš než kompromisy, aby to vypadalo, že to funguje, by se mělo řešit, jak zajistit tu skutečnou bezpečnost. Pokud někdo potřebuje zkoumat provoz prohlížeče, ať tedy prohlížeč poskytne API, na které se připojí antivir, a přes tohle API ať prohlížeč poskytuje dešifrovanou komunikaci.

Vie mi niekto vysvetlit jaka je vyhoda pouzivania dns over https nad pouzivanim dns over tls? Zatial vidim vyhodu len v pouziti portu 443.

• resolving přímo z web aplikací. Na DNS nebo TLS prý žádné API není, ale na HTTP(S) ano. Možná je i pár jiných případů kde HTTPS je dostupnější než čisté TLS. (Tahle část by jistě šla řešit i přidáním API, že?)
• server push, tedy možnost poslání nevyžádaných odpovědí. Teoreticky by tak šlo snížit latenci. Někteří si i pohrávají s myšlenkou použití DNS z toho webu na který je člověk připojen.
• se změnou defaultního portu souvisí i celkově snazší skrytí mezi webovým provozem. Technicky bude možné například mít DoH na https://www.google.com/doh a tedy nerozeznatelné dle nešifrované části komunikace, i bez šifrování SNI (ale konkrétně Google oznámil záměr DNS striktně oddělovat)
• snazší použití QUIC – bude stačit povýšit HTTP část na /3. To může pomoct při větší ztrátovosti packetů. (Výhoda asi hlavně pro bezdrátová spojení, možná jen některá?)

Nevýhod je taky řada, ale je to subjektivní. Mně osobně to přijde HTTPS pro účely DNS jako overkill. V tomhle vlákně taky ignoruji tu část okolo změny poskytovatele DNS a centralizace, to je téma samo pro sebe.