Názory k článku DNS over HTTPS: nový standard pro bezpečné a soukromé DNS
-
me (neregistrovaný)
"DNS over HTTPS" se mi zda jako dobry napad pro mobilni telefon, ale predstava, ze prohlizec na domacim PC bude ignorovat lokalni DNS server ziskany z DHCP a bude se dotazovat primo nejakeho globalniho DNS serveru me prilis netesi. Pro pristup na lokalni zdroje budu nucen pouzit IP adresy, v budoucnu pak dlouhe IPv6 adresy. Snad to pujde v prohlizeci manualne vypnout a snad bude dostupny modul DoT pro router, ktery bude sluzbu bezpecneho DNS nabizet zbytku lokalni site....
-
Filip JirsákStříbrný podporovatelV budoucnu dlouhé IPv6 adresy používat nebudete muset, protože k nim budete mít normálně záznamy v DNS. Lokální DNS jsou jedním z problémů, které způsobuje nedostatek veřejných IPv4 adres.
-
Petr M (neregistrovaný)
Sorry, ale NECHCI si platit doménu a NECHCI mít ve veřejné DNS svoje lokální stroje jenom proto, abych si nemusel pamatovat IP adresy. Je to bezpečnostní riziko a nepotřebuju, aby někdo viděl, že na 2001:abcd:ef12:5600::7 je tiskárna s webovým rozhraním. A musí se s tímhle tvým modelem řešit statisíce vypnutí/zapnutí strojů v desetititsících LAN v domácnostech ve veřejné DNS infrastruktuře (protože i domácí krabička za 500 by se stala veřejným serverem).
Takže svoje stroje mám (zatím) v doméně .local na lokálním unboundu a nic na tom měnit nehodlám. I když po 6ce chodí 80% trafficu.
Chce to nějaký "LNS - Local Naming System":
- Komunikace po TLS se zařízeníma, co budou mít registrovaný klíče (soukromí je soukromí)
- Každý zařízení se tam ohlásí při přidělení IPv6
- S timeoutem (například pro případ pádu systému nebo přerušení napájení)
- S formátem dat klasickýho DNS
- S volitelnou možností přidání odkazu na LNS do DNSPak by z pohledu uživatele byl počítač normálně vidět přes jméno jako z DNS ( např. tiskarna.local ), ale kdo nemá klíč k LNS, ten se k tomu prostě nedostane. A když chceš jít na server zvenčí, buďto si na stroji zadrátuješ LNS server natvrdo, nebo služba zkusí lns.mojedomena.tld
-
Filip JirsákStříbrný podporovatel
V době, kdy ISP poskytovali připojení k internetu, bylo běžné, že svým zákazníkům poskytli doménu (třetího nebo čtvrtého řádu) a e-mailovou schránku. Není důvod, proč by to tak nemohlo fungovat i nyní. I dnes existují na ISP nezávislí poskytovatelé DNS služeb, kde máte nějaký základ zdarma.
Mít ve veřejném DNS lokální stroje není bezpečnostní riziko. Například proto, že nemusíte povolovat přenos zóny, takže se z DNS nikdo nedozví, že daný záznam existuje, pokud předem nezná jeho jméno. A už vůbec se z DNS nikdo nedozví, že na nějaké IP adrese je tiskárna s webovým rozhraním.
Proč by se tím měly řešit statisíce vypnutí/zapnutí strojů? To se vypnutím nebo zapnutím změní DNS záznam?
Takže svoje stroje mám (zatím) v doméně .local na lokálním unboundu
To je váš problém.Chce to nějaký "LNS - Local Naming System"
Nechce, žádné takové komplikování a rozbíjení funkčnosti sítě není potřeba. Tohle řeší DNS už od okamžiku, kdy DNS vzniklo. Jiná věc je, že jsou lidé IPv4 NATy už tak zblblí, že ani nevědí, jak funguje internet – a trvají na tom, že ty problémy s NATem potřebují i v normálním internetu.Lidé chtějí používat zařízení normálně připojená k internetu, nechtějí řešit, že teď mají mobil, tablet nebo notebook připojený k domácí WiFi a k NASu nebo televizi se mají připojovat lokálním DNS názvem, a když přejdou o pár kroků dál, WiFi signál se jim ztratí, zařízení se přepne na mobilní síť a musí se přepnout na veřejné DNS názvy.
-
ja. (neregistrovaný)
V tej dobe sme tiez pouzivali dial-up. Dalsia vec, ku ktorej sa vraciat nebudeme.
V praxi je to tak, ze:
1. split horizon DNS existuje a bude existovat, bez ohladu na to, co si niektori ludia okolo DNS zelaju; existuje na to dostatocny pocet subjektov s dostatocnym impactom.
2. rovnako budu existovat lokalne resolvery;
3. pokial niektory software nebude podporovat lokalny resolver, bude v organizaciach z bodu 1 vyradeny zo zoznamu podporovaneho software a nahradeny takym, ktory lokalny resolver podporuju.
4. goto 1
PS:
a) Samozrejme, ze z DNS sa moze dozvediet, na akej IP adrese je tlaciaren alebo ine zariadenie. Staci resolvovat SRV zaznam z _ipp._tcp.domena, t.j. DNS-SD, ktoru pouzivatelia tiez chcu. Analogicky pre dalsie sluzby.
b) kazde priradenie adresy cez SLAAC alebo DHCPv6 moze mat za nasledok zmenu IP adresy. Uz len spomenuty pripad: pouzivatel sa dostane mimo dosahu wifi, preroamuje do inej siete, dostane inu IP adresu... a uz je DNS neaktualny.
c) "local naming" existuje, vola sa mDNS, ale jeho obmedzenie je, ze funguje iba link-local. Kedze existuje dostatocny pocet organizacii, spomenutych v bode 1 vyssie, ktore chcu, aby im to fungovalo cez viacero subnetov, napriklad z routovanej VPN, tak to celkom neriesi problem, ktory riesit treba.
d) ked sa niekomu strati signal, a je preroamovany do inej siete, je to pre neho signal, ze uz nema opravnenie pristupovat k danemu zdroju. Aby to opravnenie ziskal naspat, potrebuje mat VPN. VPN kludne moze byt na mobilnych zariadeniach always-on, s vynimkou definovanych AP, takze pre pouzivatela sa nic nemeni, ale prevadzkovatel bude kludnejsi, pretoze komunikacia bude vzdy sifrovana bez ohladu na aplikaciu.
-
Petr M (neregistrovaný)
V době, kdy byl dostatek IPv4, tak domácí PC byla vzácnost a pokud lezlo někam ven, tak přes modem a místo IP adresou se identifikovalo telefonním číslem. Teď jsme v situaci, kdy byt s čtyřčlennou rodinou má 2-3 smart TV, multifunkční tiskárnu s LAN, minimálně dva tablety a čtyři smartfouny + 1-3 PC. A "router" k tomu. Takže kdyby to chtěl tatínek propojit s NASem dohromady, má DNS 10-15 záznamů, který se dynamicky mění (nehledě na příchozí návštěvy atd.). Takových bytů máš v paneláku klidně 30 a takových paneláků na jenom sídlišti 50. Počítej 150 domén jenom pro takový sídliště. A hodně přehledný domény jako novak35445.zakaznik.isp.cz. A u ISPíka pěkně velký DNSko, který bude resolvovat doménu .zakaznik.isp.cz a reagovat na každý vykopnutý kabel z modemu, aby záznamy byly aktuální. Fakt super.
LNS by totiž řešilo dva problémy IPv6. Zkus automaticky narvat stroje do DNSka, když mají jenom IPv6 adresu a nemáš v síti DHCPv4 ani AHCP. Ani s *HCP na IPv6 totiž nemáš vyhráno. A domácí zónu jsem ještě nikde implementovanou neviděl.
Takhle stačí zapnout zařízení, to se spojí s domácím routerem, pošle mu podepsaný záznam, kde je a po ověření je vzdálený zařízení dostupný z domova a sosne aktuální stav. Hned vidí jména strojů v lokální síti např. file manageru. Jak když lezeš v LAN na Sambu. A to včetně těch, kdo jsou v divočině.
-
Filip JirsákStříbrný podporovatel
Vycházíte z mylného předpokladu, že se IP adresy musí přidělovat dynamicky a že DNS záznam musí existovat pouze v případě, kdy je dané zařízení dostupné. Naštěstí se věci dají dělat i podstatně jednodušeji.
-
Petr M (neregistrovaný)
IP adresa může být statická, ale v dnešní době to je spíš výjimka. Stejně jako je výjimka, že zařízení bude zapojovat někdo, kdo ví, co dělá. Takže ideální instalace je:
1) Zapojit síťový kabel, nebo vybrat WiFi a heslo.
2) Zadat jméno zařízení a zaškrtnout, že smí komunikovat ven.
3) Přihlásit se na server a potvrdit, že zařízení přidal uživatel.Že na pozadí proběhne výměna RSA a stroje si domluví práva a konfiguraci, updatuje firewall atd. přece uživatel nemusí řešit. Stejně jako konflikty IP adresy atd.
Vynucovat pevnou IP adresu a ručně přečíslovávat (rozuměj měnit /64 prefixy na 20+ strojích ), pokud ISP hrábne do infrastruktury, je přece zbytečný. A i v domácí síti si můžeš chtít zazálohovat data z jednoho komplu na druhý pomocí RSYNCu...
-
Filip JirsákStříbrný podporovatel
Když už si ten router pamatuje, že dané zařízení může komunikovat ven, jaká pro něj platí pravidla firewallu a konfiguraci, může si přece pamatovat i tu IP adresu. Statické adresy jsou pro všechny jednodušší na používání, a pokud někdo má pocit, že potřebuje proměnnou IPv6 adresu, použije IPv6 privacy extension.
Ručně přečíslovávat je opravdu zbytečné, když se změní prefix, router se to automaticky dozví a akorát rozdistribuuje počítačům v síti nové IPv6 adresy s neměnnou adresou zařízení a s novým prefixem sítě.
Nechápu, proč pořád chcete něco komplikovat, proč jednoduše nevyužijete to, co je už v IPv6 navržené – je to původní myšlenka Internetu „síť umožňuje, aby spolu kterákoli dvě zařízení v celém Internetu mohla komunikovat“, doplněná o možnosti autokonfigurace, mobilních sítí, multihome atd.
-
Petr M (neregistrovaný)
Ok. Tak zkusme triviální věc.
Mějme IPv6 only síť. V ní je vrátný s VoIP u vchodu, připojený do LAN. Uživatel má tablet s Androidem a na něm aplikaci a chce dostat notifikaci v případě, že někdo zazvoní na zvonek. Jak to jednoduše uděláš?
- Řešení s DHCPv6 + resolverem nemůžeš použít, nepodporováno Androidem
- Periodický dotazování tabletem ti bude zbytečně vybíjet baterku a generovat nepotřebný provoz na WiFi včetně kolizí atd., přímá notifikace je v tomto ohledu lepší.
-
Filip JirsákStříbrný podporovatel
Petr M: Vážně si myslíte, že můžete vyhrát porovnávání konkrétních implementací, když ten váš LNS protokol vůbec neexistuje? Co asi bude jednodušší – doimplementovat do Androidu podporu DHCPv6, nebo do celého internetu vaše LNS? Navíc pokud někdo chce používat dynamické IPv6 adresy a registrovat je v DNS, nic mu v tom nebrání, je spousta služeb, které to podporují – akorát je potřeba počítat s tím, že DNS obecně s rychlými změnami nepočítá, DNS záznamy se různě cachují, takže někdy nemusí být zařízení s novou IP adresou pod daným názvem hned dostupné.
-
ja. (neregistrovaný)
Vzhladom na principialny postoj Google k DHCPv6* bude lahsie doimplementovat ten jeho LNS do celeho internetu.
Lokalny DNS vie pomerne rychlo reagovat, staci skocit do lubovolnej firmy kde maju Active Directory a vyskusat si to.
* Google odmieta DHCPv6, pretoze umoznuje pridelit jednemu zariadeniu jedinu /128, cim by umoznil mobilnym operatorom vykastrovat tethering.
-
Ad lokal (neregistrovaný)
V prohlížeči to vypnout (zatim) jde (firefox). Dokonce šla nastavit preference zda zkoušet první dns a pak dnsohttps, a preference ipv6 prvni a dokonce i url, kde dnsohttps dotazovat (klidne lokal).
Skrývání lokálních strojů za nat mi připadá vždy jako security by obscurity. Tohle má imho řešit správně nastavený firewall. Tím, ale neříkám, že obhajuju globalni dns. A vzdy si svoje zarizeni muzete pridat docasne treba do /etc/hosts, nez si rozjedete vlastni instanci.
Btw je uz podpora dns over https v majoritních implementacích dns?
-
Security nesecurity by obscurity, pomněte, že pro domácí uživatele je základním plusem jednoduchost řešení. A NAT je výrazně jednodušší než "správně nastavený firewall", přitom pětadevadesáti procentům uživatelů stačí. já to neobhajuju, ale na SOHO se musíte dívat trochu jinou optikou než na firemní sítě.
-
j (neregistrovaný)
Ona platba za domenu je stejna pitomost jako platba za IP. Bohuzel se to takhle zmrvilo, ze si z toho par vyvolenych udelalo kseft. Protoze provoz HW by meli platit ISP z penez od zakazniku (stejne jako platej provoz routeru, switchu atd atd) a at si pak kazdej regne co chce.
Naopak, nejakou bydefault (sub)domenu se kterou si pak muzes delat co chces bys mel dostat pridelenou automaticky s podepsanim libovolny smlouvy na pripojeni.
-
Filip JirsákStříbrný podporovatel
Nedostatek IPv4 adres způsobuje, že se používají IPv4 adresy z privátních rozsahů. A tyhle IP adresy se správně nemají vyskytovat ve veřejném DNS, navíc jsou ty IP adresy z internetu běžně nedostupné – takže se to začalo „řešit“ tím, že se provozují lokální DNS servery, které poskytují DNS záznamy pro ty IP adresy z privátních rozsahů. Buď na samostatné doméně (např.
example.local), nebo na hlavní doméně (example.com), pak se ale do vnitřní sítě poskytují jiné záznamy, než do internetu. Obojí má spoustu nevýhod, v prvním případě musí uživatel rozlišovat, zda je ve vnitřní síti nebo v internetu, nejde na ty záznamy vystavit DV certifikáty od všeobecně uznávaných autorit; v druhém případě jsou zase problémy s nacacheovanými DNS záznamy při přechodu mezi vnitřní sítí a internetem.V době, kdy IPv4 adres byl dostatek, si správci sítě zbytečně nekomplikovali život dvojím DNS (a to byly řádově menším problémem jak DV certifikáty tak mobilní zařízení) a prostě se používala hierarchická struktura DNS, tj. lokální síť měla DNS zónu třetího, čtvrtého pátého řádu a v téhle zóně přidělovala názvy místním počítačům.
-
j (neregistrovaný)
Jisaku, neblabol, zase zvanis vohovne kterymu nerozumis.
Cetifikatu je upne uprdele jestli ma seznam.cz IPcko 77.75.77.53 nebo 192.168.1.2.
Stejne tak vis hovno o .local, to je automaticky pridelovana domena v pripade, ze v siti ZADNY DNS ... NENI!!!
Lokalni DNS se ty trotle pouzivaji predevsim proto, ze kdyz chcipne ta linka ven, tak se kupodivu ocekava, ze unitr vse pobezi dal. A ne ze chcipne cela firma.
A tusis ty vubec ze DNS muze IPcek poslat i vic? A ze kazda normalni aplikace vyzkousi ... vsechny? A tusis ze ti i to verejny DNS posle uplne jinou IP klidne s kazdym dotazem? Protoze se tak resi load balance?
-
Filip JirsákStříbrný podporovatel
Zase čím méně toho víte, tím více nadáváte.
Cetifikatu je upne uprdele jestli ma seznam.cz IPcko 77.75.77.53 nebo 192.168.1.2.
Což není v rozporu s ničím, co jsem napsal.Lokalni DNS se ty trotle pouzivaji predevsim proto, ze kdyz chcipne ta linka ven, tak se kupodivu ocekava, ze unitr vse pobezi dal. A ne ze chcipne cela firma.
Což závisí akorát na tom, zda máte resolver v lokální síti.A tusis ty vubec ze DNS muze IPcek poslat i vic? A ze kazda normalni aplikace vyzkousi ... vsechny? A tusis ze ti i to verejny DNS posle uplne jinou IP klidne s kazdym dotazem? Protoze se tak resi load balance?
Což opět není v rozporu s ničím, co jsem napsal. -
Petr M (neregistrovaný)
"Což závisí akorát na tom, zda máte resolver v lokální síti."
Přesně tak, lokální počítače má ve správě on. Když ho zná, vrátí IP adresu. A je mu jedno, jestli tě má má jako jirsak.blazinec.cz, nebo jako jirsak.name, nebo jako jirsak.local. Akorát použitím .local na vnitřní síti se vyhnu platbě za doménu, kterou nepotřebuju, když tam nelezu zvenčí a kterou ne každý ISP poskytne. Globální doména tam je totiž jenom na to, abych stroje vystrčil na veřejnost. A pokud změním ISPíka, nemusím měnit doménu na DNS. Proto to tak mám.
K certifikátům - https není jediná věc, kterou v LAN máš. Já tohle používám na SSH, RDP, CUPS, NFS a SMB. Router a switche jednou na HTTP, ne na HTTPS. A existuje plno dalších věcí, který na certifikáty kašlou, jako SQL. Web sever v LAN jsem zatím (mimo konfigurace krabiček po http) doma nikdy nepotřeboval a firma beztak doménu má, takže .local není problém ani tady.
-
me (neregistrovaný)
S temi certifikaty je to slozitejsi. Jeste pred cca 2 lety slo vystavit certifikat na libovolnou domenu, treba i lokal. To pred casem padlo, verejna CA dnes vystavi certifikat jen na verejnou domenu. Ale porad funguje, ze i server v lokalni siti muze mit certifikat s verejnym DNS jmenem. Takto se to dela treba v AWS, kde mate na VPC lokalni adresy z rozsahu 10.0.0.0/8, a mate lokalni DNS server (ROUTE53), ktery tyto adresy preklada na jmena jako server1.mojefirma.com. A zakaznik se na servery pripojuje pres load balancery (ELB), ktere uz maji verejnou IP adresu. Pro zakaznika je dulezity certifikat na ELB ale nektere interni sluzby mohou vyzadovat certifikaty na sluzbach ve vnitrni siti, takze dnes se musi tem strojum priradit "verejne" DNS (ktere vsak nemusi byt z internetu routovatelne/dohledatelne). Jinym resenim by bylo vytvorit si vlastni CA a mit vydavani cerifikatu plne pod kontrolou, a obejit tak omezeni, ze CA autorita jiz nemuze vystavit certifikat na domenu "*.mojefirma.local".
-
Filip JirsákStříbrný podporovatel
S temi certifikaty je to slozitejsi. Jeste pred cca 2 lety slo vystavit certifikat na libovolnou domenu, treba i lokal.
Jak ta autorita ověřila, že jste opravdu vlastníkem té domény?Ale porad funguje, ze i server v lokalni siti muze mit certifikat s verejnym DNS jmenem.
Samozřejmě. Protože certifikáty nemají nic společného s IP adresami, DV certifikáty se vystavují na doménová jména. Co s tím doménovým jménem budete dělat autoritu nezajímá a ani nemá možnost to nijak ovlivnit. -
Filip JirsákStříbrný podporovatel
Jasně, takže to selhání Symantecu, kvůli kterému teď jejich certifikáty přestávají být důvěryhodné v prohlížečích, vlastně byla běžná praxe. Vy jste docela šprýmař, že? A na důvod, proč nám žádný takový certifikát nemůžete ukázat, taky najdete nějaký vtip?
-
me (neregistrovaný)
V tom certikatu bylo samozrejem napsano komu byl vydan (firma, adresa), atd, a ty udaje se kontrolovaly a pokud by byla domena nesmyslna, tak by to asi neproslo. Ale pro domenu".local" jsme bezne certifikaty kupovali. Jedina vyhoda takto vydanych certifikatu byla, ze root CA certifikat byl pritomen v keystore klientu, takze se nemusel importovat vlastni root certifikat, coz by jsme museli delat pokud by jsme meli vlastni CA; a to bylo pohodli, za ktere jsme byli ochotni zaplatit. Ano, asi to byl bezpecnostni problem, proto se to globalne zakazalo a dns uz takovy certifikat koupit nejde....
-
me (neregistrovaný)
Tady jsou nejake odkazy popisujici, proc CA prestavaji vydavat certifikaty pro lokalni domeny a jak ma zakaznik reagovat:
https://www.ssl247.co.uk/about/blog/Deprecation-of-ssl-certificates-securing-internal-domains-why-when-and-what-to-do#.W9CJv05fjmE
https://blog.comodo.com/e-commerce/phase-ssl-certs-internal-names-reserved-ip/Kdyz nad tim premyslim, certifikat porad muze obsahovat IP adresu. Kontroluje certifikacni autorita, zda zakaznik je majitelem te IP adresy? A jaka je zaruka, ze zakaznik bude vlastnikem IP adresy i za par dni? Je nejaka garance, ze zakaznikovi IP adresa zustane do konce platnosti certifikatu??
-
Filip JirsákStříbrný podporovatel
OK, bylo to s CA horší, než jsem si myslel, o tom vydávání certifikátů na lokální domény jsem nevěděl. Doufám, že to byly alespoň OV nebo EV certifikáty, tj. že bylo jasné, komu byl ten certifikát vydán.
Pro vydání DV certifikátu na IP adresu snad pořád musíte dokázat to, že jí můžete ovládat, stejně jako u DNS. Že tu IP adresu druhý den nemusíte mít je stejné, jako u DNS – doménu můžete také druhý den prodat nebo může expirovat a koupí ji někdo jiný.
-
j (neregistrovaný)
2me: Jak CA zjisti ze ses majitelem domeny? Mno ... nijak. Proc by mela. LE staci, kdyz jim umis poslat odpoved z DNS. Coz umi ledackdo (alternativne, ze umis umistit nejakej soubor na uz existujici web ... na kterej ukazuje, co jinyho nez ... DNS). A oni tomu DNS verej. Ale browsery prej tomu DNS verit nemuzou, protoze neni duveryhodny, ale cert podepsanej LE na zaklade toho DNS je prej OK .... chmm.
BTW: Zmenit drzitele domeny je otazka ... 10s? Zhruba stejne dlouho trva vymenit zcela koser appku v nejakym storu za zcela nekoser .... at zije bezpecnost.
-
Argumenty lze předkládat i slušně!
local. Není přidělovaná doména. Je to doména pro link-local mdns, kteří tu někteří chtějí i mimo link. Není nijak závislá na přítomnosti DNS v síti. Jenom se bez něj nejvíce hodí.
Certifikát těžko obnovíte automaticky z Lets Encrypt, pokud je použitý pouze na privátních adresách. Bez dodatečných berliček ne.
A ne, DNS určitě neposílá jinou IP s každým dotazem. Obvykle jenom náhodně rotuje stejnou sadu adres. Kvůli cachování a DNSSEC by to jinak nefungovalo.
Zdá se mi to, nebo doporučujete míchat privátní adresy s veřejnými v jednom DNS záznamu? To snad není myšleno vážně?
-
SB (neregistrovaný)
Úplně nechápu, co jste tímto příspěvkem měl na mysli, každopádně správu poddomén globálními DNS považuju obecně za nekoncepčnost, to by si měla vždy řešit sama síť, na kterou by měly být dotazy DNS na poddomény delegovány. Dělení sítě a jejích adresních prostorů taky neřešíte kdesi v pr-deli v Americe. A důvodem k tomu určitě není bezpečnost, ale centralizace správy sítě do jednoho místa a rychlost, jednoduchost a možnosti správy.
-
j (neregistrovaný)
2SB: Jenze takovej system se blbe centralne kontroluje, a jeste hur direktivne ridi. Dost tezko totiz muzes naprosto komukoli zabranit, aby si tohle https://www.mfcr.cz/cs/soukromy-sektor/hazardni-hry/seznam-nepovolenych-internetovych-her dal do svyho lokalniho DNS ... a voiala, vse funguje jak ma.
Stejne tak dost blbe zaridis, aby si nekdo sracky typu bbelements.com (zdravim root) na svym DNS neposlal do /dev/null.
-
j (neregistrovaný)
Spis se to zavadi, aby se rozbil internet uplne, protoze spousta DNS ti poskyten JINOU ip podle rozahu ze kteryho se ... TVUJ DNS pta. Takze dostanes v CR trebas IPcko stroje kterej je nekde v okoli a mas k nemu po siti blizko, kdezto kdyz se zepta DNS z US, dostanes emerickou IP ...
Proste to moc dlouho a moc spolehlive funguje, a predevsim je to zcela decentralizovany, coz se musi zakazat a rozbit.
-
N/A (neregistrovaný)
V tom nenastane žádná změna oproti současnému stavu.
Záměrně vycházíte z toho, že jediným poskytovatelem uvedené služby bude Google. Klasická ukázka manipulace, jen je mi záhadou, že Vám na to vůbec někdo skočil.
Můžete spustit (např. někde v zahraničí) svůj vlastní DNS-over-HTTPS server, který bude pouhou proxy na původní DNS od Vámi zvolených poskytovatelů. Můžete samozřejmě realizovat i službu opačnou, tj. DNS pro své (legacy) klienty, která bude požadavky směrovat na DoH stroj (opět Vámi vybraného) poskytovatele.
Toto může být cesta, jak se ze zemí "za firewallem" dostat k blokované službě.
Btw. počet poskytovatelů služby DNS není kdovíjak vysoký (https://www.iana.org/domains/root/servers) a o jejich nezávislosti můžete rovněž poměrně dlouho debatovat.
-
Petr M (neregistrovaný)
Sorry, ale dejme tomu, že jsi v Brně. Tvůj ISP má resolver s cache v Brně. Nejbližší root a TLD server je v Praze. Tvůj prohlížeč obsahuje seznam DoH resolverů, ze kterých je nejbližší v Mnichově.
a) Jakou výhodu pro tebe má, když místo lokálního DNS resolveru v síti toho 100%?
b) Jakou výhodu má pro tvýho ISP, že dotazy na DNS neodbavuje cache resolveru, ale tečou mu do mezinárodního tranzitu?
c) Jakou výhodu pro BFU má, že server v Praze musí přidat ručně, zatímco klasický DNS resolver se nastaví sám rovnou v síti ISP?
d) Jak ti bod a) ovlivní latence při načítání stránek?*
* kvůli tomu vymýšlí posílání DNS odpovědí dřív, než se na ně ptáš, a podobný prasečiny s miliardou děr.
-
Filip JirsákStříbrný podporovatel
DNS over HTTPS nemá snížit latenci nebo zmenšit provoz. Jediným účelem je zajistit větší bezpečnost a soukromí i za cenu horších síťových parametrů (větší provoz, vyšší latence). Není to zamýšlené jako náhrada DNS protokolu, ale jako alternativa pro ty, kteří tu bezpečnost a soukromí potřebují. Je to jako kdybyste argumentoval tím, že TOR je pomalý a síťově neefektivní. Nebo VPN. Ano, jsou pomalé a neefektivní, ale jejich účelem není nahradit běžný provoz.
-
Filip JirsákStříbrný podporovatel
Jestli to půjde vypnout není záležitostí protokolu, ale aplikace. Stejně jako to, že to někdo implementuje jako jedinou alternativu. Podle vašich dotazů by se mělo zakázat třeba i IPv4, protože co když to v nějaké aplikaci nepůjde vypnout, nebo to bude jediná alternativa.
-
j (neregistrovaný)
Jenze to Jirsak zadnou bezpecnost, natoz soukromi NEZAJISTI, protoze NEMUZE. Pro me a 100% uzivatelu je totiz radove akceptovatelnejsi, kdyz muj ISP vidi 1% mych DNS dotazu, nez kdyz 100% uvidi guugl. Kterej samozrejme bude delat presne to co dela vsude - pekne sledovat kdo kdy odkud a kam.
A proc prave 1%? Protoze duhy 1% vidi mozna mobilni op, treti 1% ISPk zakaznika A, dalsi 1% B ... a zbylych 80% nevidej vubec, protoze to jde z lokalnich cache dotycnych.
-
K (neregistrovaný)
Problem je spis s ochranou soukromi. Na druhou stranu, v kombinaci s NATem to nemusi byt tak hrozny. Az bude mit kazdy svou verejnou IP, bude to horsi.
Na druhou stranu, kdyz prijdu do nejake budovy, prippjim se na eduroam, a zjistim, ze mi v ni nefunguje resolvovani, protoze nekdo blokuje dns dotazy na 8.8.8.8...
Doufam, ze DNS over TLS bude by defaul ignorovat udaje z DHCP a bude chodit po portu 443... -
Nejak me nenapada, ze by se to dalo pouzit k centralnimu zablokovani domeny, ale asi je moc brzo rano.
Spis se mi libi, ze to hazi dalsi klacek pod nohy uzasnemu zakonu o elektronickych komunikacich a to jejich "blokovani" na urovni DNS (ktere je samozrejme naprosto k nicemu) bude k nicemu jeste vic.
Uvidime, jake oblezlicky v DoH vymysli pro privatni DNS server ve firmach a podobne.
-
Filip JirsákStříbrný podporovatel
Jak přesně bude to globální zablokování umožněno nebo posíleno tím, že uživatelé používající DNS servery Google nebo Cloudflare budou pro přístup k těmto serverům používat DNS over HTTPS a ne klasické DNS přes UDP nebo TCP? Myslíte, že lokální ISP unese provoz pro 8.8.8.8, 8.8.4.4 a 1.1.1.1 a na svém DNS serveru bude hrdinně poskytovat překlad adres, které budou Google a Cloudflare blokovat?
-
Meh (neregistrovaný)
Misto X (= vetsiho poctu) DNS serveru budou dva, resp. jeden, protoze Cloudflare muzeme ignorovat, jeho DNS over HTTPs implementuje maximalne Firefox s uzivatelskou zakladnou vytrvale smerujici k nule.
Tzn. posileno je to tim, ze pro stejny vysledek staci provest zablokovani na jednom, misto na X mistech. -
Filip JirsákStříbrný podporovatel
Ono něco brání DNS over HTTPS implementovat komukoli jinému? Já bych si myslel, že je to vydáno jako otevřený standard právě proto, aby to mohl implementovat každý. Navíc DNS over HTTPS je jen nová možnost, současné DNS servery se tím neruší. A ve skutečnosti to bude používané spíš výjimečně tam, kde opravdu je podstatná ochrana soukromí, protože DNS over HTTPS bude logicky pomalejší, než klasické DNS přes UDP z blízkého serveru ISP. Vždyť autoři prohlížečů odmítají implementovat DNSSEC kvůli zdržení překladu, a teď by se najednou hromadně přešlo na něco ještě pomalejšího?
-
Jíra (neregistrovaný)
Jirsák, Jirsák nějak zapomínáš. Autoři prohlížečů na to už :
https://www.root.cz/zpravicky/firefox-bude-pouzivat-dns-pres-cloudflare/Jestli teda ta neochota implementovat DNSSEC nebude způsobena něčím jiným.
-
ja. (neregistrovaný)
A co brani presadzovacom DoH definovat DHCP tag pre DoH a zabezpecit jeho implementaciu tak, ako je dnes implementovane klasicke DNS? Malo by to vyhodu, ze by DoH pouzivali vsetky aplikacie, ktore volaju gethostbyname/getaddrinfo/getnameinfo a nemuseli by si implementovat DoH sami.
V DoH nie je problem jeho implemetacie do resolverov. Jeho problem je, aby:
1) aplikacie respektovali nastavenie v systeme,
2) siet mala moznost autokonfiguracie systemov prostrednictvom DHCP.Pokial si niekto vo svojej sieti nastavi 8.8.8.8 alebo 1.1.1.1, tak kludne moze. Treba ale zachovat moznost, aby si ostatni mohli nastavit to, co vyhovuje im. Aby bola autokonfiguracia a nemuseli to rucne prestavovat po kazdej zmene siete (prides z domu do firmy => prestavit. Prides z firmy k zakaznikovu => prestavit. Prides naspat do firmy => prestavit. Prides domov z prace => prestavit. Toto nikto rucne robit nebude).
-
Petr M (neregistrovaný)
Tahle možnost tady přece je i bez téhle krávoviny. Prostě si nastaví resolver podle sebe a je to. Pokud to ISP neumožňuje, je to porušení legislativy EU (síťové neutrality) a musí vysvětlit, proč blokuje provoz. Pokud to dělá jenom svévolně, je to na dost mastný flastr.
Ale nejdůležitější je, že místo tlaku na lumpy a jejich trestání můžeme furt hledat metody, jak protunelovat dvě sítě za různýma CGNATama se třema firewallama, který mají DROP na veškerý traffic, že...
-
Filip JirsákStříbrný podporovatel
je to porušení legislativy EU (síťové neutrality)
Jo, z porušení legislativy EU budou Čína nebo Rusko celí nesví a hned to napraví. -
Petr M (neregistrovaný)
Asi tak. Zase se někdo po večerech nudil, flašky s rumem už byly prázdný, tak rychle začal sepisovat RFC, než vystřízliví.
Když se člověk podívá, jak klasický DNSko funguje, rozdělí se dotazy (na root levelu se ptá jenom na TLD apod.), v síti je jeden DNS resolver, tak je ztráta soukromí minimální. S DoT útočník vidí jenom to, že se někdo ptal na TLD .cz na nějakou doménu, neví na jakou. DNS pro .cz ví, že se někdo ze sítě XY dotazoval na root.cz, ale neví kdo přesně... A díky cache v DNS ani nevidí všechny dotazy. Vypadne jeden server, odpoví jiný.
Teď se ještě vožungři můžou zaměřit na to, aby veškerá komunikace šla na "agregátor", který teprve bude komunikovat s HTTPS servery místo něho, protože někdo může podle IP adresy vidět, s kým se síť vlastně baví... Ideálně agregátor v rukách státu nebo velké firmy, která ví, co je pro uživatele dobrý.
Správný řešení je, že pokud se objeví bezpečný standard, nahrazující původní nebezpečný/nešifrovaný (telnet->ssh, ftp->sftp, dns->DoT...) a začne ho používat > 60% uživatelů na netu, za půl roku se stane povinným a za rok od dosažení 60% zablokovat komunikaci s ním na veřených sítích. Jinak se furt budou vymýšlet rovnáky na ohybáky a další krávoviny, jak to udělat, když to někdo nechce udělat správně. Takhle budou sabotéři out of busines a hotovo.
-
Petr M (neregistrovaný)
Když něčemu nerozumím, začnu tím, že se pokusím si o tom něco přečíst (a informací je tady dost). Pokud je něco nejasnýho, zeptám se.
Rozhodně bych jako začátečník nešel do toho, že bych kategoricky na serveru o autech hodnotil nějakou vychytávku kolem turba v motoru, když o autech vím jenom jak se řídí, jak zhruba funguje čtyřtaktní spalovací motor a jaký je rozdíl mezi bubnovou a kotoučovou brzdou.
-
Noname (neregistrovaný)
ad "přináší velkou výhodu v tom, že pak není možné blokovat pouze DNS provoz, který je namíchán s HTTP"
No tak tohle je totalni nevyhoda. Ja chci mit moznost blokovat DNS a http oddelene. A ne proto, abych blokoval dns a povolil http (proboha, proc?), ale abych povolil dns a zakazal http. -
ja. (neregistrovaný)
Ako ISP by som takuto vec neriesil, pretoze by to bolo na zakaznikoch.
Riesil by som to ako prevadzkovatel siete v nejakej organizacii. Boli by dve moznosti:
- zlozitejsie riesenie: pakety na DoH maju specificky obsah, so specifickym SNI (plati aj pre TLS 1.3). Dropovat tie.
- jednoduche riesenie: zaviest natvrdo proxy.Nakoniec to narobi problemy akurat v mensich firmach, ktore nemaju adminov, co maju priestor na riesenie takychto veci. Domaci pouzivatelia budu mat uplne smolu, pokial niektory z clenov rodiny nie je nadsenec, ktory to vie tiez urobit.
-
j (neregistrovaný)
Ze prej bezpecnost, to jiste ... budeme pekne vase dns prasit centralne guuglu, to aby vedel kam lezete i kdyz tam nejakym omylem nema svuj smirovaci script ... a kdyby to nahodou nestacilo, tak mu naprasime aspon certifikat (jak jinak nez povine zverejnenej v prave jeho ulozisti), takze si to stejne dohleda.
-
Cek (neregistrovaný)
"Lidi bezne nejsou ochotni tolerovat moji volbu nepouzivat zadny DNS server z jejich infrastruktury."
Ty zas nejsi ochoten tolerovat jejich pozadavky pri vyuzivani jejich infrastruktury, proto je nejjednodussi ji nepouzivat - kde je problem? Obe strany budou spokojene.
Kdezto Ty, jako spravny dobroser, to chces kvuli svemu malemu problemu naordinovat globalne vsem....
-
Petr M (neregistrovaný)
1) Používáš jejich síť.
2) Oni určují pravidla jejich sítě.
3) Oni odpovídají za to, že co se v síti děje, je v nějakých zákonem daných mantinelech.Pokud nesouhlasíš s pravidly, zkus domluvit lepší, nebo (v případě blokování služeb s ohledem na síťovou neutralitu) požádej regulátora o asistenci, nebo používej jinou síť. Místo blokované ad-hoc WiFi můžeš pořád používat mobilní data.
Decentralizovaný systém kupodivu funguje. Doteď nemají BFU problém dostat se na libovolnou webovku, která není na seznamu MFČR. Jedinej problém je, že někteří nepoužívají DNSSEC (což se dá řešit přes VPNku na domácí resolver). Zpoždění bude +/- stejný, jako když požádáš HTTPS server, aby se zeptal DNS serveru,... Domácí resolver máš pod kontrolou, můžeš si ohlídat, že třeba neposílá plnou URL na root DNS. A že používá DNSSEC. Kdo ti tohle zaručí u prostředníka?
A pokud jde o VPNku, tak to by měl být standard. Pokud nechodí (třeba na WiFI v hospodě), je potřeba kontaktovat pingla a vysvětlit mu, že jsi měl v plánu u nich udělat firemní akci pro padesát lidí, ale protože se bezpečně nedostanou z noťasů na firmu, slušně se ho zeptej, jestli v okolí není někdo, kdo to umí. Když to udělá 20 lidí, najednou tam VPN pojede.
-
Aha, takze zase znova, stejne jako v RFC samotnem, tady v tom clanku, jako ve vsech clancich - slabe, az zadne ospravedlneni, proc je DNS over TLS nedostacujici a *potrebujeme* to hnat pres HTTPS a zaroven *je to dobry napad*. Presne nula vysvetleni, krome "Mozilla to chce a spouste lidem to prijde jako dobry napad". Ale vsechny vedlejsi efekty, co to bude mit na cely Internet, kdyz jedna sluzba resolvuje jinak, nez *VSECHNY* ostatni...
No proste akorat pekne protazena demonstrace demence lidi od browseru, kteri aktualne diktuji "otevrene" standardy, co na to mam rict. Jak jsem se rozciloval a rozcilovat budu, proces muze byt stokrat verejny, kdyz je debata od zakladu spatne - jenze to je potom diskuze na urovni "twl necpete ty tekuty dinosaury do tech vsech veci, nespalujte je jenom kvuli presunu o par kilometru vedle" - ale kterej blbec by tuhle radu poslouchal, realny dusledky nasledku jsou jeste daleko, na co bychom se zabejvali uz dneska takovou podradnou otazkou, jestli je to *od zakladu* vubec dobry napad.
No co. Potom bude stacit zariznout tcp 443 a beznemu Blbounovi Frantovi Ubrecencovi prestane jit pro nej jeho cely znamy Internet. Pritom mu panove ale stacilo bloknout Facebook a vubec nebylo potreba takhle prevadet DNS nekam jinam.
Na anonymitu reseni *MAME*. A ano, je to DNS over TLS.
Jeste jsem nevidel jeden legitimni argument, proc zabalit legitimni normalne prenositelny provoz do HYPERTEXT transfer protocolu. HYPERTEXT, proboha. To uplne zni jako Name Services, ano, dava smysl...
Kdyz je Internet rozbity a nikdo se jakoze nedostane nikam (port bla bla byva blokovan), nemeli by soudruzi resit radeji to, jakozto pricinu, nez to vsechno presouvat na jeden *jeste snaze* zablokovatelny port, uplne slepe a k smichu, aniz by to vubec kdy melo potencial vyresit ten puvodni problem?
Mne asi praskne prava koule... (z tech dvou kristalovych v zasobe, samozrejme, bo tak moc silne predikuju, ze je to totalni ptakovina, co posle Internet jeste rychlejsi zkratkou do spiraly irelevantnosti, co se vyvoje civilizace tyce, protoze se vyvoj jaksi zastavuje a nastupuje jenom tezka komerce a triskani penez, coz je fakt tezko vyvoj a posun nekam, kdyz se misto odstraneni vohejbaku soustredime na lepsi rovnak...).
-
jouda (neregistrovaný)
Tak mozna myslenka zabezpeceni dotazu je uslechtila, ale uz si dokazu zive predstavit praxi:
- Vsechny Androidy tam budou mit prednastaveny jeden konkretni (napodobne pro jine platformy)
- Typicky BFU si to nikdy v zivote nezmeni
- I kdyby se typicky BFU proti vuli Googlu vzeprel a v tom dotazu kterej tam pri vytvareni uctu je jestli GDPR souhlasi s synchronizaci dal ne, tak stejne jeho historie browseni v podobe DNS ober TLS/HTTPS potece dal k Velkemu Bratrovi
- Pro tech par zlomku procenta uzivatelu, kteri vedi ze si maji zvolit jineho DNS poskytovatele jestli se chtej zbavit smirovani stejne uz ted pouzivaj napr. always on VPN a pro ne to nepredsavuje zadnou zmenuZaverem nevim jestli vic neduverovat providerovi, ktery samozrejme ze zakona loguje taky, ale aspon se obvykle nezivi prodejem soukromi, nebo jednomu z nekolika globalnich hracu, ze kterych nejmene u jednoho je vseobecne smirovani zakladnim business modelem.
-
j (neregistrovaný)
Uz tu par desitek let mame ... voiala ... ipsec, takze netreba ani vymejslet kokotiny na tema kazdej protokol budem sifrovat zvlast, kazdej jinak, a nejlip, jeste kazdou cast jinak. Viz trebas narovnavak na vohejbak na tema nesifrovany hlavicky https ...
Jenze vis, to by misto sracek musel nekdo neco realne delat ... https://bugzilla.mozilla.org/show_bug.cgi?id=14328 ... tohle je muj oblibenec, na vyroci zapaluju svicky - podle poctu let, ale brzo to budu muset omezit, spis na pocet desetileti.
-
peci1Stříbrný podporovatelProc se nepocita s tim, ze by to melo system-wide konfiguraci, pro kterou si prohlizec proste sahne stejne jako u normalniho DNS? Je to kvuli HTTPS certifikatum?
-
Petr M (neregistrovaný)
Jo, udělají si to stylem aktualizace aplikací na Widlích. LibreOffice zobrazuje v pravým horním rohu ikonu, že mám stáhnout novou verzi. Pak s objeví u SysTraye bublina, která chce novou Javu a TortoiseSVN zase házelo požadavky na aktualizaci do okna. A vždycky taková aplikace leze tam, kam nemá ( = co má JRE co o své vlastní iniciativě hledat na webu novější kopii sebe sama? ), vždycky se to píše jenom tak mimochodem a vždycky je tam velký riziko bezpečnostní díry... A celý snažení přitom funguje jako rovnák na ohybák, protože M$ nedokáže zajistit aktualizaci včetně aplikací třetí strany.
-
j (neregistrovaný)
Kazda distribuce linuxu umi pridat libovolnej pocet externich repository, klidne i lokalnich, kde ta aplikace je. Aktualizauje se to pak cely sakum prdum jedinym prikazem. Na widlich naprosto neresitelny.
Mimochodem, soudruzi z M$ pokrocili, uz neumej pres widloupdate aktualizovat ani VLASTNI tvorbu....
M$ Visual ... pouziva presne to co psal Petr M - cosi kdesi si to samo stahuje a samo instaluje.
M$ SQL management studio - to te posle na web, kde si mas ten exac stahnout a nainstalovat.Neexistuje zadnej zpusob jak bys centralne zjistil, kde je co v jaky verzi, a jestli na to je nebo neni verze novejsi, natoz abys zjistil, co ze ten kterej patch vlastne dela. JO, muzes to instalovat, pak dopadnes jako aktualne s widlema 10 ... proste ti to tu a tam smaze nejaky ty soubory, nu coz, soubor sem nebo tam ...
-
Petr M (neregistrovaný)
Když tam aplikace není, hodím tam 3rd party repo.
A aktuální systém včetně aplikací mám kompletně pořešený jedním řádkem v terminálu:
sudo nice -n 20 dnf -y update
Pokud je tam i core, tak restartuju, jinak postupně naběhnou jiný verze. A dělám to, když chci já, ne nějaký pošuk za oceánem se systémem a zbytek nikdy.
-
SB (neregistrovaný)
Já jsem to pochopil tak, že server DNS over HTTPS bude moci provozovat, kdo bude chtít. Takže stejně jako s DNS dnes. Takže jediné 2 věci, o kterých má smysl diskutovat, jsou
1. zda to není nadbytečný protokol (kvůli čemuž se ale Koule nepřestane točit),
2. zda to nebudou aplikace vynucovat, ale to není chybou protokolu, ale aplikací, a nijak se to neliší od vynucování běžných serverů DNS aplikacemi. -
ja. (neregistrovaný)
Ano, bude si ho moct prevadzkovat, kto bude chciet, akurat v diskusii je zopar dalsich bodov:
3. Bude tvoj lokalny resolver aj nejaka aplikacia pouzivat?
3a. Firefox umoznuje konfiguraciu... cez about:config. Budu bezni pouzivatelia menit resolver po kazdej zmene siete (s laptopom aj niekolkokrat denne)? Tazko.
3b. Sila defaultov: ani IE6 nebol povinny, a aky mal podiel a co sposobil.
3b. Nezrusia casom tuto moznost, ze "ved aj tak to nikto nepouziva"? (pri danom ux... ani sa nedivim). Uz sa v minulosti stalo.
4. Preco vobec obchadza system? Systemovy resolver tiez moze pouzivat DoH, dokonca konfigurovany cez DHCP, takze pouzivatelia nemusia nic rucne konfigurovat. Aplikacie pouzivajuce getaddrinfo() a spol. ani len netusia, ci sa pouziva 53/udp alebo DoH, je to pre ne transparentne. Preco musi byt browser nieco extra?
-
Petr M (neregistrovaný)
"Preco musi byt browser nieco extra?"
Aby blbečci v Mozille mohli vykázat i jinou činnost, než změny loga a genderový války mezi klukoholkama a holkoklukama.
Bude to jako se SocialAPI. S velkou slávou se to zavádělo, pak to celý svět potichu ignoroval a pak se vykázala práce na odstranění SocialAPI, protože to nikdo nepoužíval a běželo to bez toho líp. Nic se nezměnilo, ale 2x se vykázala práce na vylepšení produktu. Tož asi tak...
-
me (neregistrovaný)
Tady je pekne srovnani s ostatnimi technologiemi vcetne DoH. Prekvapive, dnscrypt vychazi jako vitez...
;-) Ale mozna ze je skutecne nejlepsi... V realnem svete ma malou podporu.
https://dnscrypt.info/faq -
me (neregistrovaný)
Uvedomil jsem si jednu slabinu. Prohlizec nejprve musi ziskat IP adresu DNS resolveru, treba "cloudflare-dns.com".
Prvni dotaz tedy nemuze jit na jmeno ale na IP adresu DNS serveru. Nejprve jsem si myslel, ze v certifikatu nebudou IP adresy, ale jsou tam, takze se pocita, ze prvni dotaz muze jit i na IP adresu treba 1.0.0.1 nebo 1.1.1.1. Ale IP adres je v certifikatu omezene mnozstvi, takze by firewall mohl tyto adresy zablokovat a tim DoH prakticky vyradit. Prohlizec by se musel pokusit ziskat IP adresy pres klasicke DNS a tam uz by zase mohlo dojit k filtrovaniCertifikat lze ziskat treba timto prikazem
$ gnutls-cli --print-cert cloudflare-dns.com 443 < /dev/null | tee x.pem
Vlastni data o DNS ulozena v certifikatu pak timto; takze staci zablokovat pristup na 4 IP adresy (2xIPv4+2xIPv6):
$ openssl x509 -in x.pem -noout -text | grep DNS DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001 -
me (neregistrovaný)
Jeste jeden komentar. Chybejici IP adresa v certifikatech Google pro DoH je problem:
$ gnutls-cli dns.google.com 443 < /dev/null $ host dns.google.com $ gnutls-cli 172.217.23.206 443 < /dev/null
Srovnejte s
$ gnutls-cli 9.9.9.9 443 < /dev/null $ gnutls-cli 1.0.0.1 443 < /dev/null
-
Seesa (neregistrovaný)
Pár poznámek:
1. Nelíbí se mi jak prohlížeče přebírají stále více funkcí OS. Celý OS má být jen bootloader pro Chrome/Firefox/cokoli? Jaký to má smysl?
2. Tak jako prohlížeč teď obsahuje seznam důvěryhodných certifikátů (kterým Já nedůvěřuji ale při každé aktualuzaci se mi nacpou z5), bude teď obsahovat seznam důvěryhodných DNS?
3. Argumenrace proti NAT/PAT je jak v kruhu - něco jako: Vchodem do jeskyní foukalo, tak jsme vymysleli dveře. Potom někdo přišel na to, že když dveře zamkne, nedostanou se dovnitř zloději. Teď ale máme tepelné clony a vchody jsou od toho aby se jimi vcházelo, tak všechny dveře zrušíme a zloděje budem řešit správně proškolenou ostrahou v každém vchodu..
4. V každé firmě je několik systémů, které slouží pouze pro vnitropodnikové potřeby. Vystavováním jakýchkoli informací o těchto systémech mimo firmu znamená vytvoření potenciálního postranního kanálu pro dosud neznámé vektory útoku na interní systémy.. Proč? -
Proc tihle zastanci IPv6 pusobi jako zastanci zniceni soukromi? Co takhle zdrojova adresa a dohledatelnost skrz ni? Ne vsechno jde vyresit stateless firewallem. A zdaleka ne kazdy ma povinnost logovat spojeni na sve NATovaci GW (zdravim czfreecka, ktera se ochrany soukromi svych clenu jeste nevzdala), takze ospravedlneni logovanim v ramci “stejne si te dohledaji” neni validni argument.
-
Filip JirsákStříbrný podporovatel
IPv6 nezakládá povinnost přidělovat koncovým uživatelům statické IP adresy ani nezakazuje hnát provoz přes proxy nebo přes NAT. Pokud uživatelé takové nesmysly budou chtít, třeba protože budou věřit tomu, že to ochrání jejich soukromí, může ISP klidně měnit IP adresu v jednom paketu třeba čtyřikrát, přidělovat uživateli každou půlhodinu jinou IP adresu, v serverovně rozprašovat ocet a veškerý provoz hnát přes homeopatický krystal. „NAT jako ochrana soukromí“, to je nové „NAT jako firewall“?
-
Filip JirsákStříbrný podporovatel
Dobře, napíšu to stručně: váš předpoklad, že NAT nějak přispívá k ochraně soukromí uživatele, je mylný. Existuje mnoho způsobů, jak identifikovat konkrétní zařízení i uživatele za NATem. Nevím, co bych měl na měnění IP adresy každou půl hodinu vydržet – samozřejmě by se měnila automaticky a já jako uživatel bych nic nepoznal. Dokonce speciálně pro paranoidní uživatele, kterým vadí mít statickou IPv6 adresu, existují SLAAC privacy extensions. EUID64 není IPv6 adresa.
Navrhnout lepší řešení můžu, ale nejdřív to bude chtít, abyste vy popsal problém. Bez problému není řešení.
