Az ISP-k ellenzése dacára az összes jelentős internetes böngészőben megjelenik a DNS-over-HTTPS támogatás

Mind a hat fő böngésző-gyártó azt tervezi, hogy támogatja a DNS-over-HTTPS (vagy DoH) protokollt, amely a DNS-forgalmat titkosítja és elősegíti a felhasználó magánéletének védelmét az Interneten.
A DoH segítségével a felhasználó DNS-forgalmát láthatatlanná teszi a harmadik féltől származó hálózati megfigyelők, például az internetszolgáltatók számára.

Míg a felhasználók szeretik a DoH-t, és áldásosnak tartják azt adatvédelmi szempontból, addig az internetszolgáltatók, a hálózat üzemeltetők és a kiberbiztonsági cégek enyhén szólva, ki nem állják. Kiszivárgott egy, az amerikai törvényhozás félrevezetésére szánt dokumentum is, aminek célja a DoH Egyesült Államokban történő tiltásának elérése volt.
A DoH beállítása Chrome, Edge, Firefox, Opera, Vivaldi böngészőkre és részletek itt találhatók. Safarira egyelőre nincs DoH-támogatás. Ugyanakkor a Safari fejlesztői általában minden új szolgáltatás bevezetésével késnek, és az Apple a közelmúltban a felhasználói adatvédelemre összpontosító szolgáltatásokat erősítette, tehát nagyon valószínű, hogy a DoH bevezetése a Safariban is hamarosan megtörténik.
A DoH elterjedése miatt egyesek főképp a Mozillát tartják felelősnek. Korábban már a HUP is foglalkozott azzal, hogyan lehet a Firefox böngészőben a DoH-ot bealláítani.

Hozzászólások

Nem értek hozzá pontosan, de akkor hogy fogják nemzetbiztonsági szinten figyelni a forgalmat?
aminek hozzáteszem egy csomó kötelező pozitívuma is van

pl: nemzetbiztonságilag kifogásolható oldalak szűrése
statisztikák készítése hogy a lakosság melyik oldalakat milyen mértékben látogatja és ez hogy alakul
malware-k "központjainak" ISP általi tiltása
megfigyelések
reklámok kezelése

Mindez nemzeti kézből átkerül majd google kézbe?
 

Kazahsztán próbálkozott ilyennel, de már elmúlt miután a böngészők blokkolták ezt a root cert-et.

https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack

Jelenleg amúgy nincs ilyesmire szükség a blokkoláshoz, mert a domain (SNI) titkosítatlanul utazik https csatlakozáskor is. Már van rá megoldás, de nincs elterjedve: https://www.cloudflare.com/ssl/encrypted-sni/

A mozilla nem küldi (jelenleg) az EU forgalmat a cloudflare-nek, az amerikai forgalmat viszont igen.
Ennek a hátránya, hogy központosítja a DNS-t egy nagy céghez.
Az NSA-nak ez jó, mert már csak 1 helyre kell bekopogtatnia.

(Másrészt az USA-ban valóban, a nagy szolgáltatók sniffelik a dns kéréseket és
eladják a gyűjtött adatokat reklámcégeknek.
EU-ban ez nem jellemző.)

A google a chrome-ban nem tervezi default-ba bekapcsolni,
illetve ha bekapcsolja akkor is a userhez tartozó ISP-nek küldi a DNS forgalmat DoH technológiával, ha az támogatja: https://www.theregister.co.uk/2019/09/10/chrome_78_dnsoverhttps/

Eddig minden munkahelyem lekérték a userek dns lekérdezéseit.

Illetve szerintem minden szolgáltató átbogarássza azokat, csodálkoznék ha nem lenne ez is az egyik kötelezettségük.

https://dnscrypt.info/

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Vagy mi köze van az államnak ahhoz, hogy a lakosság milyen oldalakat látogat?

http://zrubi.hu/2015/nav-szef/

 

a linkek havonta változnak így a cikkben a legtöbb már nem elérhető, de könnyen megtalálhatóak egy kis guglizással.

íme néhány aktuális:

https://www.nav.gov.hu/szerencsejatek/archivum/blokkolt_honlapok

https://www.nav.gov.hu/szerencsejatek/archivum/gyik/nemnevesitett

 

Ébredj fel, Neo!

Míg a felhasználók szeretik a DoH-t, és áldásosnak tartják azt adatvédelmi szempontból, addig az internetszolgáltatók, a hálózat üzemeltetők és a kiberbiztonsági cégek enyhén szólva, ki nem állják.

nagyon jó. ez remekül mutatja hogy nem csak igény hanem szükség is van rá.

"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

Ez csak a céges rendszergazdáknak szívás, és ők joggal nem fogják komálni, bár céges eszközökön biztosan tíltható lesz, a hátombötüsek már úgy is biztos felkészültek rá, csak a kóbor apácákat vezethetik álhőbörgéssel.

Nálam "Not available on your platform."   (Chrome 78)

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Könyvjelzőed. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kipróbáltam firefox (cloudflare az alapértelmezett) alatt. Ha létező domain szerepel a kérésben, akkor szépen működik, wireshark alatt látszik hogy nem látszik dns kérés. Ha viszont a cloudflare nem ismeri a domaint, pl. kutyafasza.hup.hu, akkor rápróbál az os dns kiszolgálójára is, így már látja az ISP a forgalmat.

Azzal egyébként előrébb vagyunk, hogy az ISP nem látja a DNS kéréseinket, de a cloudflare igen?

Nem kell feltétlenül a cloudflare-t használnod. Ha jól gondolom, akkor egy vps-en csinálasz egy saját DNS szervert, aztán megtolod VPN-en keresztül, és máris aggódhatnak az arra kíváncsiak. (Az is lehet, hogy a VPN-t is kihagyhatod.)

READY.
󠀠󠀠‎‏‏‎▓

btw jelenleg nincs lehetőség saját szerver hozzáadására, 3 választási lehetőséged van chrome-ban: google, cloudflare quad9

amúgy ha választanom kell, hogy az ISP-hez vagy egy központi céghez fusson be az összes dns lekérdezésem, akkor én az ISP-t választanám.

A DoH súlyosan károsítja Ön, és billentyűzete egészségét!

Where do you want to go today?
[nobody@salcay:~]$_

Egyes europai orszagokban a nem helyben adozott szerencsejatek nem szerettet, tehat
a szolgaltatokat kell revanni hogy dns csomagokat elfogjak es a nem adozo oldalakat jol letiltsak ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem pontos. A szolgáltatót arra veszik rá, hogy az oldalt elérhetetlenné tegye, és tájékoztassa az azt elérni szándékozó felhasználót, hogy ez nem véletlen.

Az, hogy ezt a szolgáltató legegyszerűbben és legpraktikusabban DNS manipulációval tudja megoldani, csak egy technikai részletkérdés.

"A megoldásra kell koncentrálni nem a problémára."

Bookmarkolom. OS szinten, ha a gép egyben routol is, kicsit macerásnak tűnik, de mindenképpen kevesebb terheléssel jár, mintha a böngésző végezné el a feladatot. Kicsit tesztelem a plugint, ha jól teljesít, akkor a DoH-ot ráteszem. Köszi a linket.

READY.
󠀠󠀠‎‏‏‎▓

"Encrypted SNI

Your browser did not encrypt the SNI when visiting this page."

Melyik titkosítja?

Egyébként ennek az lesz a vége, hogy a nagyobb cégeknél tiltva lesz belülről minden titkosított kapcsolat. Már most is sokan csinálják, hogy céges CA-tól kell root certet felvenni és mindent azzal titkosítanak kliensek fele és csak kifele mennek az adott oldal kulcsával titkosítva a csomagok. Ha ezt a böngésződ beállítása nem engedi, akkor te nem netezel. Használd a céges böngészőt, ami megfelelően van beállítva/fordítva!

> Melyik titkosítja?

By-default egyik sem, firefox-ban be lehet kapcsolni: about:config > network.security.esni.enabled

Egyelőre még nem végleges a specifikáció: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

Egyébként ennek az lesz a vége, hogy a nagyobb cégeknél tiltva lesz belülről minden titkosított kapcsolat.

A https oldalak 90+% -a nem érhető el http-ről.

Nem vagyok benne biztos, hogy DOH+ESNI mellett működni fognak az ssl proxy-k: A publikus kulcs a dns rekordban van, a kliens egyből arra titkosítja a kapcsolatot, így a köztes szereplőknek nincs lehetősége belenyúlni ebbe. (így akár a root cert-ek is feleslegesek?)

Persze ha van hozzáférésed a kliens géphez, akkor tiltható az DOH/ESNI használata (még)

" A publikus kulcs a dns rekordban van, a kliens egyből arra titkosítja a kapcsolatot,"

Még mindig nem érted. Nyugodtan titkosíthatja, csak éppen nem fog tudni kijutni a hálózatból, mert a tűzfal megfogja.
Ha a dolgozó panaszkodik, akkor jön a válasz: "Használj megfelelő böngészőt (a cégest vagy állítsd át a sajátodat)!"

Ez a veszélye ennek az egész játéknak, hogy pont az ellenkezőjét fogják elérni a célnak vagyis még durvábban bele fognak tekinteni a cégek az adatforgalomba. Lehet egyébként ez a burkolt cél, hiszen így lesz hivatkozási alapjuk. Minden mögött a pénzt kell keresni..

Erről az egészről egyébként ez jut eszembe :)
https://xkcd.com/538/

Miért előnyös az, ha eddig

  • az internetszolgáltatóm
  • a Cloudflare
  • a Google
  • bármilyen más ingyenes

DNS szerver helyett

  • a Cloudflare
  • bármi más

címre irányítom titkosítva a DNS forgalmamat?

Onnantól az a szolgáltatás fogja látni az IP címemről jövő igényeket. Miért jobb, ha annak a cégnek adom, és nem az első részen említett cégeknek?

Mi a garancia, hogy a Cloudflare nem használja arra, mint az összes többi cég? Mármint elméletben semmire, a gyakorlatra meg nincs garancia, hogy nem használják bármire is.

Oké, ha jól értem, ha a torrent oldalt DoH-os böngészőben nézem, akkor a szolgáltatóm nem látja, hogy melyik domain-re csatlakozom, de ha már megvan a torrent site ip címe, akkor a kommunikáció már nyilvánvaló, hogy a torrent site-tal zajlik, és megadom a jelszót, látja, hogy mit töltök le, az URL-ből is és magában a HTTPS adatfolyamban is benne van minden, ha nem használok VPN-t.

Sakk-matt,
KaTT :)

Így van. És ha már az ISP mindenképpen tisztába van a forgalmammal (globális VPN láncon áthajtottól eltekintve), akkor már inkább ott tartanám.

Mégiscsak jobb, mint behúzni a játékba egy külföldi céget, és külföldön tartani dns kéréseim naplóját.

"A megoldásra kell koncentrálni nem a problémára."

Azért jobb, mert így a Google (meg a többi nagy cég) még jobban követheti a tisztelt felhasználókat. Semmi más haszna nincs ennek a lépésnek. Ha valóban a DNS forgalom hitelesítése és titkosítása lett volna a cél, akkor a DNSCrypt elterjesztése és tovább fejlesztése mellett kampányoltak volna ennek a taknyolt-barkács megoldásnak a bevezetése helyett.

Igazából kezdem úgy érezni, hogy ebből a szempontból a Google az új Microsoft, aki az új taknyolt "szabványaival" és túlsúlyával teljesen szétcseszi a netet.

Zavard össze a világot: mosolyogj hétfőn.

Minden kérés IP alapú. Csak HTTP 1.1 óta a "Host:" headerben átadja melyik domain-t kéri.
Magában a kérésben csak az aloldalak vannak, például: GET /kiskutya.html
"Host:" headert pedig akár egy böngésző pluginnal is tudsz módosítani, így mindenféle DNS kérés és /etc/hosts fájlba való felvitel nélkül.

Az SNI független a Host header-től és a böngésző sem fog más domain-re kiállított cert-et elfogadni.

Tavaly óta a Google és az Amazon enforcolja a Host és az SNI egyezését: https://www.theverge.com/2018/4/18/17253784/google-domain-fronting-disc…

Igen, de ez csak HTTPS-re vonatkozik. Én HTTP-ről beszéltem. De például levelezőszerveremre is a reverse DNS-ben szereplő domainhez x.y.szolgaltato.net-hez kértem tanúsítványt, így IP alapján is lehet titkosítva kapcsolódni hozzá. 

Minden kérés IP alapú

Ha innen nézzük, minden kérés MAC address alapú. Ismerjük a hálózati rétegeket, és most jelezted, hogy minden átmegy a harmadik rétegen. Tény. De a https nem layer3. Ezért nem értem hogy a hozzászólásomtól független tényt közölsz, vagy cáfolod éppen.

"A megoldásra kell koncentrálni nem a problémára."

most nem azért, de az ISP bármikor ránézhet az IP címekre és azt bármikor visszafejti domain névvé, ha olyanja van, nem?

Régi szép idők... amikor még a Windows-os rendszergazda 2 publikus IP címet vetetett a céggel, mert a hosting teremben tárolt szervernek 2 domain nevet kellett kiszolgálnia egy Windows-os IIS szerveren, mert nem tudta beállítani, hogy 1 IP címen több weboldal is elérhető legyen... :-) Még rontva a helyzeten ezek után kijelentette, hogy ő szakember, mert 1 hálózati kártyán is be tudott állítani 2 különböző IP címet, és nem szükséges 2 hálózati kártya a szerverbe, hogy ezzel milyen sokat takarítanak meg... :-)

Sakk-matt,
KaTT :)

Kipróbáltam. Így múlt időben. a Firefox legújabb verziója olyan szépen homokórázott VPN mellett ezzel a beállítással, még egy tabot sem tudott betölteni, hogy öröm volt nézni.

Szóval kikapcsoltam a francba. Ezt nem nekem, és nem vállalati környezethez találták ki.