DoH privacy/security/performancia egyensúly egészséges megtartása?

Security-all

Sziasztok!

Arra lennék kíváncsi, hogy van-e valakinek valamilyen gyakorlati, jó megoldása a DoH kontrollálására.

Kifejezések tisztázása:

  • DoH == DNS over HTTPS, a DNS kérések HTTPS-en utaznak 443/tcp-n
  • DoT == DNS over TLS, a DNS kérések TCP payloadként TLS-be tekerve utaznak 53/tcp-n

Háttér:

A környezet home environment, szóval semmi üzleti kritikus cumóról nincs szó. Fogalmazzunk úgy, hogy az otthoni infra permanens test lab mindenféle use-case-ek életszerű, mindennapi használattal járó kitesztelésére.

A cél:

DNS kérések utazzanak externet szakaszon secured transporton, de a belső DNS szerver ne legyen megkerülhető.

Per pillanat az intra DNS logika a következőképpen néz ki. Adott két ANS melyek a belső zónákat szolgálják ki. Adott két CNS, melyeken a conditional forwarderek az ANS-ek felé küldik a belső zónákra irányuló kéréseket. Minden egyéb kérést a CNS hostokon, localban figyelő dnscrypt-proxy továbbítja az upstream NS-ek felé DoT-on. A border GW-en minden 53-ra érkező kérés a belső CNS felé van forwardordolva tűzfal szabályokkal.

A jelen logika célja többrétű:

  • A CNS-ek DNS alapú szűrést végeznek, így minden hálózatra kötött kliens bizonyos szintig védettséget élvez: ad, kártékony oldalak, session replay scriptek, stb. Pl. mobil folyton OpenVPN-en lóg és a CNS-eket kérdezi, szóval nem kell a szűréssel kliens oldalon bohóckodni.
  • Egy esetleges belső host kompromittálódás esetén DNS alapú védelmi réteget biztosít. Pl. feltételezve hogy a kártékony kód logika hardkódolt DNS szervereket tartalmaz, az abba az irányba küldött kérést is az intra CNS terminálja, így szűri. Nyilván a védettség nem 100%-os, ez csupán az egyik védelmi réteg.
  • A külső hálózaton a DNS kérések TLS-be tekerve utazzanak.

Viszont az utóbbi időben nagyon úgy néz ki hogy a DoH irányába mozdulnak el a browser vendorok [1]. A gondom ezzel az, hogy kb. pofán csapja a fenti logikát és teljesen kicsúszik a fent vázolt kontroll a kezemből. Értem én a privacy törekvéseket és bizonyos fokig még egyet is értek velük, de keresek valami egészséges egyensúlyt.

Látom pl. hogy nginx-ben implementálható a DoH/DoT GW [2]. Ha pl. a róka nagyon szeretne csak DoH-on beszélgetni, ez erre a részére megoldást jelenthetne. Viszont továbbra is kérdés a kimenő, DoH felett utazó, nem kívánatos kérések kontrollja. Nyilván a HTTPS tartalom vizsgálatára és annak függvényében valamilyen döntési mechanizmusra van szükség. Amire gondolni tudok az egy HTTPS proxy, ami érzésem szerint felhasználói oldalról nézve performancia overhead-et jelentene az egyébként normál HTTPS forgalom esetén is. Emellett, tekintve hogy ez feltételezi a teljes HTTPS forgalom vizsgálatát, meglátásom szerint éppen a HTTPS-sel járó privacyt csapja pofán. Permanens eavesdropping ha úgy tetszik.

Szóval a poszt célja kettős:

  • Mit gondoltok erről az egész DoH témáról a poszt címe és a fentiek kontextusában?
  • Van-e valamilyen gyakorlati, kiegyensúlyozott megoldási ötletetek arra, hogy az eddigi működési logika DoH mellett megmaradjon, feltételezve hogy várhatóan az hamarosan ki lesz kényszerítve.

--
[1] https://blog.mozilla.org/blog/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/
[2] https://www.nginx.com/blog/using-nginx-as-dot-doh-gateway/
 

( toMpEr | 2020. 04. 26., v – 20:18 )

Szerkesztve: 2020. 04. 26., v – 20:21

Szerintem jelenleg az a legegyszerűbb, ha blokkolod a Firefox default DoH szervereit, így az fallback-el normál dns-re:

 - https://mozilla.cloudflare-dns.com/dns-query

 - https://dns.nextdns.io

https://wiki.mozilla.org/Security/DOH-resolver-policy

Lehet, hogy az IP-k kizárásával más CF szolgáltatásokat is blokkolsz, de talán a CF gondolt erre és nem rakott mást arra az IP-re.

Ha a saját, lokális DNS szervered támogatja a DoH-t a feloldáshoz, akkor a biztonság sem sérül. (ha csak nem törik meg a DNS szervered)

Ha jól értem azt javaslod hogy blokkoljam a hostokhoz tartozó címeket, azaz ezeket:

$ dig +short A mozilla.cloudflare-dns.com
104.16.249.249
104.16.248.249
$ dig +short AAAA mozilla.cloudflare-dns.com
2606:4700::6810:f9f9
2606:4700::6810:f8f9
$ dig +short A dns.nextdns.io
45.90.28.0
$ dig +short AAAA dns.nextdns.io
2a07:a8c0::

Köszönöm az ötletet, viszont az a bajom ezzel a megoldással, hogy így legfeljebb a Firefox specifikus DoH kérések lennének kezelve, az is csupán ideiglenesen.

Én sokkal inkább generális megoldást keresek, en bloc kontrollt a DoH felett. Másképp megfogalmazva, egyáltalán semmilyen DNS kérés ne mehessen kifele az intráról anélkül hogy az ne lenne engedélyezve függetlenül attól, hogy hogy az DoH típusú vagy sem. Jelenleg a hagyományos kérések és DoT felett megvan ez a kontroll. A DoH, mivel HTTPS-en megy, sokkal problémásabb.

> Én sokkal inkább generális megoldást keresek, en bloc kontrollt a DoH felett. 

Mivel egy teljesen standard https lekérdezésen keresztül működik a DoH, így csak a https csomagok kibontása után fog kiderülni, hogy mi van benne, szóval ilyet csak https proxy-val tudnál csinálni.

Köszönöm, eddig eljutottam én is.

Amire gondolni tudok az egy HTTPS proxy, ami érzésem szerint felhasználói oldalról nézve performancia overhead-et jelentene az egyébként normál HTTPS forgalom esetén is.

Ezért is lett a poszt:

van-e valakinek valamilyen gyakorlati, jó megoldása a DoH kontrollálására.

Itt a hangsúly a gyakorlati megoldáson van a fent vázolt use-case-re.

FDNS was designed to run as a local DoH proxy on a Linux desktop

Köszönöm, de úgy tűnik hogy ez pont az ellentéte annak amit keresek. :)

Nem az a gondom hogy hogyan tudom elrejteni a DNS kéréseket a hálózat üzemeltető szeme elől. Azt bármikor megoldom. :) Épp az volna a lényeg, hogy hogyan lehet kontrollt szerezni saját infrán az intráról kifele menő DoH kérések felett. Azaz pont hogy ne mehessen ki semmilyen DNS kérés csak az amit a hálózat kínál, mászkáljon az DoH-on, vagy sem.

Bizonyos szempontból nem az amit keresel, bizonyos szempontból igen szerintem. Arra gondolok, hogy ha ismertek a DoH kiszolgáló szerverek, akkor azokat lehet blacklistelni, tűzfalazni, és akkor oda nem megy ki https forgalom. Az fdns több DoH szervert is alkalmaz.

Valaki majd csinál az smtp rendszereknél rendszeresített, RBL-hez hasonló "adatbázist" a DoH szerverekről (IP, hosztnév, stb.), aztán arrafelé a forgalmat szépen lehet tiltani proxyból, tűzfalból ki hogy szereti.

https://www.securityweek.com/identifying-dns-over-https-traffic-without-decryption-possible-researcher

Érdes cikk, köszi!

Valaki majd csinál az smtp rendszereknél rendszeresített, RBL-hez hasonló "adatbázist"

Ezzel megint csak az a gondom, hogy valamilyen diszkrét listát feltételez ahelyett, hogy a kifele menő nem kívánatos DNS kérések teljesen kezelve volnának. Pl. mi akadályoz meg abban egy rosszindulatú kódot, hogy hardkódolt asdf címet használjon névfeloldásra és mondjuk egy intra OS fertőzés esetén a rosszindulatú kód adja a névfeloldást. Egy ilyen forgatókönyvnél a host teljes DNS forgalma el van terelve tetszőleges címre.

A cikkben vázolt packet méret vizsgálat is csak bizonyos fokig tűnik megoldásnak, mégpedig ezért:

In short: if you see long-lasting TLS connections, with payloads that rarely exceed a kByte, you probably got a DoH connection

Itt a "rarely" és a "probably" rész öli meg a DoH packet egyértelmű beazonosíthatóságát. Tegyük fel packet méretre lövünk. Ilyen esetben a normál, méret határ alatti HTTPS packet is áldozatául eshet a szűrésnek, ahogy méret határ feletti DoH packet is átcsusszanhat. Mindenesetre majd játszok vele kicsit tcpdumppal, lehet hogy egy több lépcsős logikának ez jó kiindulási alapja lehet.

Jó volna látni valamilyen gyakorlati megoldást ahol az intrán a DNS feletti kontroll megmarad, de szignifikánsan nem csorbítja a normál HTTPS forgalom performanciáját valamint a HTTPS tartalomba sem kell belenézni. Azaz megtartani a DoH privacy/security/performancia egészséges egyensúlyát.

Őszintén szólva én a DoH-ot tévútnak tekintem, ahogy azt a koncepciót is hogy a browser dolga volna egyedi DNS-t megszólítani.

( zrubi v | 2020. 04. 27., h – 10:48 )

Szerkesztve: 2020. 04. 27., h – 10:49

Ahogy definiáltad is:

DoH == DNS over HTTPS, a DNS kérések HTTPS-en utaznak 443/tcp-n

 

Ez azt jelenti, hogy a HTTPS feltörése nélkül neked (mint infrastruktúra, tűzfal, hálózat üzemeltető) semmiféle beleszólásod nincs abba hogy a kliensek mit csinálálnak egy titosított csatornán belül.

(Ez egyébként talán rávilágít arra az eddig sokszor figyelmen kívül hagyott tényre, hogy manapség a TCP/443 porton BÁRMILYEN nem kívánt szolgáltatás (VPN, Proxy, DNS, stb) szabadon használható a legtöbb biztonságosnak hitt céges hálózatból is)

 

Szóval, ha már otthon érzed, hogy ez lehet hogy probléma, akkor mit szóljon egy céges hálózat üzemeltetője??

(persze, ott lehet hogy "full control" van a kliensek felett - legalábbis ebben a tévhitben élnek)

 

Őszintén szólva én a DoH-ot tévútnak tekintem, ahogy azt a koncepciót is hogy a browser dolga volna egyedi DNS-t megszólítani

Teljes mértékben egyetértek.

zrubi.hu

Nagyjából így látom én is. Sejtésem szerint hamarosan érdekes sztorik látnak majd napvilágot ezzel kapcsolatban. Szvsz a DoH hosszú távon pont hogy biztonság csökkenést eredményez annak fokozása helyett. Nem is igen értem miért nem a DoT irányába mozdul el az iparág. Nekem úgy tűnik hogy minden szempontból jobb megoldás volna a DoH-hal szemben ha már mindenképpen a TLS-be tekert DNS kérés a cél.

Szerintem a biztonságnak eddig is csak az érzetét keltettük az informatikában. Ha bármilyen rendszer internetre van kötve akkor belülről lehet onnan adatokat szivárogtatni, ha az ember ráér. 0 és 1 re kódolva minden adat lassacskán kijut, akárhogy szűröd is: "Indián füstjel".

Ha biztonságra vágynánk  akkor application level packet inspection, magyarul adott porton keresztül csak a jóváhagyott tartalmú adatfolyam mehet és nincs gdpr bs, mert man-in-the-middle dekódolni és proxyzni kell a titkosított adatfolyamatokat is, különben tárva-nyitva az út. De sajnos, mint minden "szűrés" itt is az idő és a kódolás kérdése csökkenti a szűrés hatékonyságát.

Pandora szelencéje DoH hátán: 

https://www.researchgate.net/publication/236278772_On_Botnets_that_use_DNS_for_Command_and_Control 

2011-es cikk.

Igen, elég ijesztő. Rémlik egy hasonló cikk pár évvel ezelőttről, ott is a TXT rekordokban volt tárolva a kártékony kód. Lehet hogy pont ugyanerről volt benne szó, de nem ez a tanulmány volt.

Persze, 100%-os biztonság nem létezik. Még akkor sem ha az Antarktiszra költözteted a szervert egy ajtó nélküli atombunkerbe hálózati elérés nélkül 100 méter mélyre ásva. Idő, erőforrás és akarat kérdése. A biztonság és a kényelem mindig is ütötte egymást. De azért éjszakára csak bezárom a bejárati ajtót, hiába tudom hogy van olyan betörő aki simán átjut rajta ha nagyon akar.

( SzBlackY | 2020. 04. 27., h – 10:54 )

  • Van-e valamilyen gyakorlati, kiegyensúlyozott megoldási ötletetek arra, hogy az eddigi működési logika DoH mellett megmaradjon, feltételezve hogy várhatóan az hamarosan ki lesz kényszerítve

Mind Chrome-ban, mind Firefoxban Group policyból letiltható a DoH, FX-nél saját címre is irányíthatod (lehet, hogy Chrome-ban is, de most csak egy notepad-ban néztem rá az admx-re).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Group policy Windows környezetet feltételez, jelen use-case-re ez nem illik. Az intrán lévő 13 headless vm-nek FreeIPA adja az alap infrát.

Igen, FX egyedi intra DoH szerverre írtam a lehetséges nginx alapú DoH GW-t. De őszintén, kicsit túlbonyolítottnak érzem már ezt a megoldást is: FX megszólítja az intrán figyelő nginx-et. Az átproxyizza a CNS-ek felé a kérést, amik továbbadják a dns-crypt proxy-nak, mely az upstreamnek. Jó mókának tűnik egy DNS-jellegű probléma debugolása egy ilyen setupnál.

( thuthu | 2020. 04. 27., h – 16:00 )

Ezt csak a Firefox nézi? https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsn…

Talán lehet meg lehet próbálni eltéríteni, hamisítani a DoH  szervert, amit keres. 

Esetleg efféle, ha van már: https://tools.ietf.org/html/draft-peterson-doh-dhcp-00

(Bár szerintem egyik se jó. A forgalom alapján azonosított DoH szerverek is csak addig jók, amíg nem csinálnak mögé felhőt, amit persze majd DoH alapján kérdeznek majd le. :)

Bár a "van-e valakinek valamilyen gyakorlati, jó megoldása a DoH kontrollálására."  mondat és a hálózaton kikapcsolod a DoH-ot (vagyis csak kéred, hogy lécci kapcsoljátok ki) és utána használod az eddigi  DNS infrastruktúrádat, nekem egy kicsi hasonlóságot mutatott. De  bocs, igazad van, nem teljesen a nyitó kérdésekre ment a válasz. Csak ötletek, amiket még nekem is ki kellene próbálni.

Talán ezekkel kevesebb forgalmat kellene vizsgálni a https proxyban. De ha a segíteni akarsz a felhasználón, aki azért akar DoH-ot használni, hogy kikerülje a gonosz szolgáltatót (téged), nem fog menni a HTTPS-sel járó privacy pofán csapása nélkül.  

Na de ha végiggondolod épp a privacy törekvést öli meg hosszabb távon a DoH. A júzer a privacy jegyében elkezdi használni. A hálózat üzemeltetője meg nem biztos hogy nagyon szeretne egy ilyen rést az infrán. A reakció természetesen az, hogy akkor innentől kezdve minden HTTPS tartalmat vizsgálunk. Végső soron akkor jól járt a júzer aki privacyt akart? Nem pont ezzel nyírjuk ki a HTTPS lényegét?

Meg azért különböztessük meg a hálózati szakaszokat. Teljesen legit elgondolás, hogy rejteni akarja a júzer a DNS kéréseket mondjuk ISP elől. Az már kevésbé, hogy rejteni akarja az intranet üzemeltetője elől. Talán esetleg nyílt hálózaton, de ott meg nem a DNS kérések plain mivolta kéne legyen a legnagyobb gondja. Nyílt hálózaton már eddig is illett VPN-t használni.

Arról nem is beszélve hogy mennyivel növeli a hálózati forgalmat, hiszen plusz két absztrakciós réteget még rárak: HTTP, TLS. Én, mint gonosz szolgáltató annyira nem örülnék neki ha valaki így abuzálná a saját infrámat.

Ha a DNS kéréseket akarjuk TLS-be tekerni ott a DoT, saját infrádra, externet szakaszra. Ugyanúgy megadja a privacyt, mégsem kell ilyenek miatt fájjon az ember feje.

De ha a segíteni akarsz a felhasználón, aki azért akar DoH-ot használni, hogy kikerülje a gonosz szolgáltatót (téged)

A fentiek miatt ezzel nem tudok egyetérteni.

Lehet nagyon cinikusan hangzik, de az eddigi profilozást, adathasználati szokás értékesítési játékot most mások szeretnék lefölözni "privacy marketing"-be csomagolva. DNS forgalom alapján eddig is elég pontosan be lehetett lőni egy-egy user internethasználat szokás profilját ISP szinten. Most mások is kérnek ebből a tortából. A többi meg ráadás játék nekünk informatikusoknak. Lásd a "location data" analóg témakört. A másik oldalt ahova a kérések mennek ki ellenőrzi? Hiszünk benne mert új? Vagy majd jön a kínai csip spyware duma, közben a nagy I összes processzora könnyen támadható. Évekkel később majd fény derül...

Nem hangzik cinikusan, nekem is hasonló aggályaim vannak. Mindemellett mondjuk egy pár upstream DNS randomizált használata DoT felett és local caching fenntartása mellett a DNS alapon való profilozás nem tűnik annyira triviálisnak. De nincsenek illúzióim, Hadooppal dolgozom, láttam már cifra dolgokat. Esetleg egy teljesen elosztott rendszer jelenthet megoldást, de látjuk hogy a Tor sem ezüst golyó.

Az egész internet már a marketingről szól ahol a júzer a disznó és örül neki hogy a gazda ingyen ad tetőt a feje fölé és még mindennap eteti is (csupán utaltam egy karikatúrára mielőtt valaki beleköt).

A minapi kedvencem: https://www.youtube.com/watch?v=mh_NpUu0LS4

Ez se újdonság, de szépen szemlélteti milyen hajmeresztő dolgokat engednek meg maguknak bizonyos "szolgáltatások".

> A reakció természetesen az, hogy akkor innentől kezdve minden HTTPS tartalmat vizsgálunk.

Erre megoldás az Encrypted SNI, ami elvileg lehetetlenné teszi a https proxyk létezését, mert nem fogja tudni a proxy, hogy milyen domain-hez kell certet generálni, mert az is titkosítva van: https://blog.cloudflare.com/encrypted-sni/

The server publishes a public key on a well-known DNS record, which can be fetched by the client before connecting (as it already does for A, AAAA and other records).

Azért egy kicsit elgondolkodtató a dolog DoH kontextusban. Ahhoz hogy meglegyen a kliensnek a szerver publikus kulcsa épp a DNS szervert kell megszólítania, azaz a DoH kérés TLS handshake szakaszában legalább az első ClientHello-ban azért csak ott kell legyen a plain host név az SNI extensionben. Ha ez igaz, akkor egy DoH blokkolás célú HTTPS proxy logika nyugodtan átengedheti a TLS1.3 forgalmat ahol az SNI extension encrypted, a maradékot viszont továbbra is vizsgálnia kell.

Ahogy a leírás is írja az egész megoldás csak akkor lehetetleníti el a HTTPS proxyt ha DoH vagy Dot felett DNSSEC-kel megtámogatva kéred le a rekordot. Nekem úgy tűnik, hogy semmi nem akadályoz meg abban hogy a kliens rekord kérésére saját publikus kulcsot válaszoljak, és onnantól az SNI-t a proxy ki tudja nyitni. A proxy pedig termination pointként nyugodtan nyithat újabb TLS-t a cél host felé már annak a publikus kulcsát használva az SNI titkosításához. Feltételezve persze, hogy a kimenő DoH kéréseket tudom blokkolni és kikényszerítem a saját NS használatát.

Vagy félreértek valamit?

Igen, ha kontrollálni tudod a kliens által használt dns szervert, akkor el tudod távolítani az ESNI rekordokat, vagy akár az általad leírt mód is működhet, bár el tudom képzelni azt is, hogy a hostok publikus kulcsa a böngészővel együtt érkezni fog a hsts preloadhoz hasonlóan: https://github.com/chromium/chromium/blob/master/net/http/transport_sec…

( debtamas88 | 2020. 04. 27., h – 22:45 )

Van rá megoldás, dobd ki a böngészőt!
Majd lesz DOH mentes böngésző.

Ez a DOH lényegében egy "backdoor" funckió, ezért nem kívánatos.
Ennyi erővel már beépített VPN-t is beleégethettek volna a "böngészőbe".

Topiknyitóban is benne van, ez egy olyan "protokoll" amit arra találtak ki, ami ellen most küzdeni kellene.

Van még választék:
-Vivaldi (chromium)
-Pale Moon (firefox)
-WaterFox (firefox)

Igen, erről szól a post. Mindazonáltal kérlek próbálj függetleníteni a browsertől ha már hozzászólsz a topichoz. Miért gondolod hogy browser váltás orvosolja a _bármilyen_ intra hálózati kliens által indított DoH kérések problémáját? Nem, nem orvosolja, ez favágó módszer.

Bizonyos esetben igen, a probléma forrásának megszűntetése a probléma megoldása feltételezve hogy ráhatásod van a probléma forrására. De a probléma forrása nem a browser, hanem a DoH önmaga. Azzal, hogy egy bizonyos kliens alkalmazást átkonfigurálsz arra, hogy ne használjon DoH-ot, azzal azon az egy bizonyos kliens alkalmazáson orvosoltad a problémát. A megoldási javaslat alkalmazás rétegen akar kezelni egy alacsonyabb réteggel összefüggő problémát.

Mégis milyen relációban áll pl. headless szerverekkel vagy tetszőleges hálózati kliens alkalmazással a browser? Hadd ne linkeljem be a korábbi commenteket. Nagyon szívesen folytatom tovább a diskurzust miután elolvastad figyelmesen a topic nyitót, a korábbi commenteket és értelmezted a tartalmukat. Nem browserekről van szó.

Nem browserekről van szó.

Akkor döntsd el, hogy mit akarsz. Mert ha ezen a szinten akarsz szűrni (1. láthatóan nincs ráhatásod a használt alkalmazásokra, 2. nem akarod MITM felbontani és elemezni a forgalmat és 3. nem fekete/fehér listázni akarsz), akkor kb. cseszheted. Tfh. kitalálsz valami mintát, ami alapján sikerül a DoH-ot szűrnöd. Mi akadályoz meg engem abban, hogy feltegyek egy random webszerverre egy saját scriptet, ami kap egy DNS kérést és visszaad egy DNS választ (kb. DoH, csak nem a standardot követve...) és azt használjam a headless szervereden levő akármilyen kliensből?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

1. láthatóan nincs ráhatásod a használt alkalmazásokra, 2. nem akarod MITM felbontani és elemezni a forgalmat és 3. nem fekete/fehér listázni akarsz

Itt valami félreértésről lehet szó. Nem arról van szó, hogy fekete/fehér listázást nem szeretnék, hiszen az is egy védelmi réteget biztosít szóval simán mehet. Mivel azonban diszkrét lista, nem érzem a csupán fekete/fehér lista fenntartását kielégítő megoldásnak.

Ahogy feljebb szó esett már több commentben is róla MITM módszer szintén jó védelmi réteg lehet, de szintén nem biztos hogy megvalósítható vele a kielégítő védettség pl. encrypted SNI esetén. A kliens alkalmazásokra meg egyáltalán nem jellemző hogy 100%-os ráhatásod volna még a magad által üzemeltetett infrán se. Gondolj csak egy 0 day exploit kihasználásával járó fertőzésre.

Feljebb már többször eljutottunk oda, hogy ha DoH-ot akarunk szűrni, nyilvánvalóan HTTPS proxyra van szükség. De nagyon nem mindegy hogy:

  1. Egyáltalán kielégítő megoldást nyújt-e. Lásd encrypted SNI problémakör.
  2. Milyen performancia ára van.
  3. Szükséges-e egyáltalán minden forgalmat részletesen vizsgálni, vagy lehetséges-e valamilyen egyéb logikával megállapítani a forgalom jellegét. Lásd. fentebb packet mérettel összefüggő tanulmány.

Mi akadályoz meg engem abban, hogy feltegyek egy random webszerverre egy saját scriptet, ami kap egy DNS kérést és visszaad egy DNS választ (kb. DoH, csak nem a standardot követve...) és azt használjam a headless szervereden levő akármilyen kliensből?

Ez is egy kiváló meglátás, de a post fókusza kifejezetten a DoH.

Még egyszer, a post célja a privacy/security/performancia kiegyensúlyozása DoH szűrés céljából. Ezek egyértelműen ütik egymást, ezért voltam kíváncsi hogy van-e valakinek gyakorlati, működő, használat mellett megvalósított implementációja, vagy el kell indulnom a kályhától.

Persze az eddigi ötletek is elég hasznosak voltak. Viszont tartok tőle ilyesmivel nem nagyon foglalkoznak a hupperek, de legalábbis eddig még nem posztolt senki gyakorlati megoldást.

"Viszont tartok tőle ilyesmivel nem nagyon foglalkoznak a hupperek"

Nem csak a hupperek, úgy általában senki.

Céges hálón vagy simán feltörik a HTTPS-t, vagy a probléma megértéséig sem jutottak még el...

(tapasztalat)

 

"Otthon" meg a kit érdekel kategória az egész security  :D

 

Szóval ez amolyan szélmalomharc, egy-két ideig óráig lelkes "donkihótéval" világszerte.

Szerintem.

zrubi.hu

"Otthon" meg a kit érdekel kategória az egész security  :D

Ebből a szempontból kicsit elborultabb vagyok az átlagnál. Zónázott hálózat, OS hardening, Kerberos, TLS, ilyesféle. Van akinek a legó, nekem ez a kikapcsolódás. :D Cserében élesben nem kell szopnom vele hanem rutinból mennek.