A DoH (DNS HTTPS-en keresztül) nagyon egyszerű. Ahelyett, hogy a szerver 53-as portjához (mondjuk a jól ismert 8.8.8.8-hoz) lépne, és UDP vagy TCP csomagon keresztül kérne tartományt, a DoH szabványosítja a GET vagy a POST felépítését HTTPS tartományra, és a válasz az A és AAAA rekord (az RFC nem határoz meg más rekordokat) az IP-vel. Természetesen vannak további részletek, például a zseniális megoldás, amelyet a fejléc tartalmaz gyorsítótár-vezérlés TTL lesz. Minden végpontok közötti titkosítás, nyilvánvalóan. Emlékszel, amikor egy szállodában át tudtál alagutazni a DNS protokoll (általában korlátlan) HTTP böngészésen, hogy ne fizess a WiFi-ért? Nos, hátra.
A DNS protokoll olyan, mint egy teve. Az idő múlásával annyi súly nehezedett rá, hogy kénytelen volt elviselni annyi tapaszt, gyógymódot és plugint, hogy most türelmesen mászik át a sivatagban, anélkül, hogy bármilyen problémát teljesen megoldana, kivéve azt, amit terveztek. És egyik vagy másik okból a kívánt biztonságot és/vagy adatvédelmet még nem sikerült elérni. Nem azért, mert nem javasolták (valójában több tucat alternatív vagy kiegészítő javaslat létezik egymásnak), hanem azért, mert egyiket sem fogadták el tömegesen. A DNSSEC-től kezdve a DNS-en keresztül a TLS-en keresztül (DoT), amely, mint sejteni tudja, ugyanazzal a DNS-protokollal folytatódik, de egy TLS-alagúttal (például POP3 és SPOP3). A DoT, a DoH-hoz legközelebbi dolog, a 853-as portot használja, és hatékonyan elrejti a forgalom tartalmát és hitelesíti a szervert. Ezt az RFC-t 2016-ban javasolták. De nem vált annyira népszerűvé, mint várták. Ez biztosan nem váltotta ki a DoH-ban keltett felkelést.
Egyébként van még DNS a DTLS-en, DNS a QUIC felett, DNS a TOR felett ... Van még egy DoH, amely Json-t ad vissza, de ez egy speciális adaptáció, amelyet a Google használ (bár a Cloudfare is csinálja) erősebbnek ( például lehetővé teszi más rekordok megtekintését, nem csak A vagy AAAA).
| Ezek a képek bemutatják, hogyan kell használni a DoH-t a Google és a Cloudfare API-k segítségével, és hogyan hoz vissza egy Json-t |
A DNS a hálózat egyik legrégebbi protokollja, és mindig is biztonsági fejfájást okozott (a születésnapi támadástól a Kaminsky-problémáig). Minden világos, az UDP lehetőségével (még könnyebb hamis csomagokat injektálni ...). Katasztrófa még támadások nélkül is, mert a szervereket kormányok irányíthatják, és így átirányíthatják vagy blokkolhatják a kéréseket. És mindezt teljesen átlátható módon, magánélet és integritás nélkül (mert a DNSSEC nincs annyira kialakítva, mint kellene). Az Internet alapjait egy olyan protokollra bíztuk, amely nem tudta, hogyan védje meg magát technológiai szempontból, hogy a megoldásokat tömegesen alkalmazzák (vagy ezt nem akarták, pontosan ugyanezen okból), és amelyre mindenféle javítás és baromfi alkalmazták, hogy ne törjék meg az örökséget. Annyira, hogy Végül a biztonság elérésére irányuló javaslat úttörő volt: adja át a felbontást az adatsíknak. És ha ez nem lenne elegendő, a DoH a felbontást nem bízza meg a rendszer globális DNS-ében, de figyelmen kívül hagyhatja azt a DNS-kiszolgálót, amelyet általában a DHCP biztosít ... így minden alkalmazás képes a HTTPS-en keresztül szokásos módon megoldani.
De ez nem rossz, nem igaz? Nem lenne csodálatos, ha senki nem látná, amit megpróbáltunk megoldani, és nem tudta azt semmilyen módon módosítani? Álcázza le a kéréseket és a válaszokat a HTTPS-ben, és hagyja, hogy a tömeg elszálljon egy kikötőben, amelyet senki sem tud kivágni, 443. Nincs több kém vagy korlátozás. Ezt ígéri a DoH, de többet tör, mint amennyit javít?
A böngészők ünneplik és már megvalósítják is. Lehetőségük van energiát szerezni, nem csak azért, mert már ismerik a HTTPS technológiát, és ez kevésbe kerül nekik, hanemino, mert beágyazhatják a böngészőbe az alapértelmezés szerint lekérdezett felbontót… Például a Google már nem férne hozzá mindenhez, amit a világ megold a híres 8.8.8.8-as verzióján keresztül, de Kiterjesztené a DNS-t használók százalékos arányát (kb. 13%) mindenkire, aki már használja a Chrome-ot, ami már 60%. "Biztonságos DNS-nek" nevezi. Látott már lehetőséget arra, hogy kitörjön a rendszer DNS zsarnokságából, ahol a legtöbb domain megoldódik: a böngésző. A Google már használja a DoH-t az Intra alkalmazásában (közzétéve a Jigsaw Operations alatt), amely pontosan a DNS-zárak megkerülésére szolgál.
Az Android a maga részéről a TLS-n keresztül valósítja meg a DNS-t a legújabb verziójában, bár nem tették ezt túl nyilvánossá. Jelenleg a Cloudfare a DNS-üzletággal is foglalkozik, ezért a híres 1.1.1.1 vállalat a Firefoxszal együttműködve megbízható felbontás-szolgáltató. Valójában a Firefox DoH-ja TRR (Trusted Recursive Resolver) néven ismert. Ígérd meg, hogy ne használd a szükséges felhasználói adatokat. Például a Cloudfare vállalja, hogy eltávolítja ezt a beküldést a DNS-kérésben használt első 3 oktettből. Az első 3 oktett elküldése a Google és az OpenDNS által 2011-ben támogatott lépés (RFC-vel) a DNS teljesítményének javítása érdekében IP-hely szerint.
| A Chrome végrehajtja, de még nincs kezelőfelülete. Benne vannak. https://chromium-review.googlesource.com/c/chromium/src/+/1194946 |
| A Firefox már beépíti, alapértelmezés szerint le van tiltva |
Másrészt a TLS másik súlyos problémája általában az hamis tanúsítványok használata a szerveren, amelyek lehetővé teszik a titkosítás megszakítását és a kémkedést. Ez a rossz gyakorlat a kormányok számára elérhető, és paradox módon a DoH gyenge pontja a TLS használatában, különösen akkor, ha a DoH-t pontosan azért tervezték, hogy a kormány ne korlátozhassa az internetet a hagyományos DNS-en keresztül. Egy kormánynak csak be kellene jönnie egy hamis tanúsítvánnyal a DoH-ban is (ahogy más oldalaknál szokták tenni). De míg a DoT kényszeríti a rögzítés használatát az RFC-ben, a DoH-ban még csak nem is javasolják ... Nem láttad előre?
| Megfigyelhető, hogy a TLS-en keresztüli DNS-ben a csapok megjelennek (in dnsprivacy.org), de ugyanez nem történik meg a DoH-ban. Még nem is kedvelt. |
A rögzítés eléréséhez, hasonlóan más megoldásokhoz (például a megszűnt HPKP-hez), a DoT TLS kézfogás után az ügyfél kiszámítja a tanúsítvány SPKI-értékét a nyilvános kulcs és más X.509 adatok alapján. Pontosan megegyezik a HPKP csapokkal, csak nincs első áthaladás. Az ügyfélnek előre meg kell ismernie és tárolnia kell őket.
Ez állítólag megtöri az ismert internet paradigmáját. Legalább kétségeket ébreszt. Valójában Paul Vixie (a DNS egyik atyja) radikálisan ellene van, és támogatja a DNS használatát TLS-en keresztül HTTPS helyett. Az egyik oka annak, hogy azzal érvel, hogy (a hangos spoilerek ellenére) végül hagyta, hogy kinyissa egyfajta Pandora dobozát, lAz elemzők elveszítik az irányítást a hálózat felett, a monitorozás képességét, a jelátvitel és az adatprotokollok összekeverednek ... Nem szabad megfeledkezni arról, hogy ez a modell még nagyobb energiát ad a böngészőnek, ezért annak, amelyiknek ma a legnagyobb a böngésző részesedése: a Google. A Firefox átláthatóbb politikát folytat ebben a tekintetben, bár a Cloudfare szövetségének köszönhetően érdekes információkhoz juthat. Bárhogy is legyen, túlságosan központosítjuk a DNS-t, amely természeténél fogva decentralizáltan született?
És mi van a biztonsággal oly gyakori dologgal, mint a tartományok DNS-szintű szűrési képessége? Nos, a DoH-val ez nem lehetséges a böngésző folytathatta az adathalászat vagy a parancs ellenőrzését annak ellenére, hogy blokkolta a vállalat DNS-ben. A rosszindulatú programoknak teszünk szívességet a felhasználók magánéletéért és a böngésző teljesítményéért cserébe?
De a DoH új lehetőségeket is nyit. Ahhoz, hogy ez működjön, HTTP/2 multiplexelést használnak, ami viszont más utakat nyit meg, köszönhetően nyom amely lehetővé teszi, hogy több domaint oldjon meg egy mozdulattal. Ezenkívül csökkenti az SNI szivárgásának problémáját. Miért? A HTTP/2-ben a kapcsolatokat újra felhasználják. A webhelyhez való első csatlakozással a böngésző már ismeri azokat a webhelyeket, amelyeket ugyanaz a szerver üzemeltet, és újra felhasználhatja ugyanazt a kapcsolatot a látogatásokhoz. Ha a kapcsolat titkosítva van ... a csatornát újból felhasználják anélkül, hogy újra el kellene küldenie az SNI-t. Mivel kevés oldal van már egyetlen szerveren, ez legtöbbször megtörténik.
Összefoglalva: helyi nyelven, figyelmes a böngészőkre és ha valami olyasmit figyel meg, amely nem felel meg a domainjeinek feloldásakor a rendszereiben, akkor már tudja, hova kerülhetnek a felvételek; a globális ... hogy megnézzük, milyen új paradigmákat hoz nekünk ez a protokoll.