Door Erik van Straten: Door Anoniem: - Ten eerste: ... Dat met DNS al sinds jaren voor een security-filter gekozen kan worden, doet er niets aan af dat het kan.
Zoals Anoniem van vandaag 10:20 ook aangeeft: dat een filterende DNS-provider nu zijn diensten ook via DoH aanbiedt, betekent alleen maar dat
nóg een DNS provider DoH ondersteunt. Met de discussie of DoH wel of geen goed idee is, heeft dit
hooguit iets te maken als ooit de oude DNS infra is opgedoekt en blijkt dat je alleen nog maar kunt kiezen uit
filterende DoH providers - die zelf (of in opdracht van een derden) bepalen wat jij wel en wat jij niet mag zien.
Ik had slechts gereageerd op de vermeende security problemen van DoH.
Inzetten op een kwalitatief goed security-filter voor DoH lost het gros van deze problemen op. Meer heb ik niet willen zeggen.
Niet over de uitvoering ervan, en dus ook niet of hierbij wel of niet van bestaande (DNS)diensten gebruik moet worden gemaakt. Het gaat slechts om het (theoretische) principe. Voor mijn part komt er een wereldwijde club die dit filter regelt of weet ik veel wat. You name it. Het gaat mij er slechts om dat dit een deel van de oplossing zou kunnen zijn om DoH veiliger te maken. Enterprises willen geen DoH? Nou, mij best, dit hoeft nu ook niet. En als er goede redenen voor zijn dan verwacht ik ook niet dat Mozilla dit in de toekomst onmogelijk maakt.
Door Anoniem: - Als je reeds draaiende malware hebt, kan een rogue DNS-domein net zo weinigzeggend zijn als een IP-adres.
In de praktijk probeert de meeste malware langdurig "te overleven" op gecompromitteerde systemen, en communiceert (soms of vaak) met C&C (Command and Control) servers. Vaak draait die serverfunctionaliteit op gehackte servers van nietsvermoedende eigenaren waardoor de IP-adressen ervan, tot de C&C functionaliteit in gebruik wordt genomen, nog niet op blacklists staan. Enige tijd nadat de C&C server actief wordt, zal het IP-adres aan blacklists worden toegevoegd en/of zal de betreffende server (meestal door de hosting provider) "uit de lucht" worden gehaald.
Met DNS i.p.v. DoH wordt zo'n situatie er dus niet veel gemakkelijker op, want het lijkt een doodgewoon domein?...
Malware die van fixed IP- adressen gebruik maakt is zo geen lang leven beschoren. Om dat te voorkomen hardcoden de malwaremakers meestal geen IP-adressen, maar domeinnamen, waarbij de bijbehorende DNS-records die zij publiceren een zeer korte levensduur hebben (d.w.z. de tijd dat tussenliggende DNS-servers gevraagd wordt om de relatie domainnaam -> IP-adres te cachen). Dit worden fast-flux netwerken genoemd.
Zoiets vermoedde ik al, maar bedankt voor de bevestiging.
Het is overigens ook mogelijk dat de malware een doodgewone onopvallende https-verbinding opzet met zo'n gekaapte server waar de malware alleen maar even het actuele ip-adres van de C&C-server ophaalt.
(deze verbinding hoeft niet aan officiële DoH-specificaties te voldoen, en is dus ook niet als zodanig te detecteren)
Vervolgens haalt de malware na verloop van tijd (zodat er geen verband met deze https verbinding lijkt te zijn)
via een
andere https verbinding bij dat opgehaalde IP-adres zijn laatste instructies op.
M.a.w.: malware is en blijft een steeds moeilijker te detecteren probleem, dankzij https.
(krijgen we nu ook weer meteen weer -"vloek, zucht, klote https, weg ermee"- van het forum?...)
Door Anoniem: In elk geval meldt een "vreemde" DoH-server zich nog met een ander certificaat terug dan je default DoH-server. Dit kan een hint zijn.
Dan zul je
alle vanaf internet ontvangen certificaten moeten onderzoeken en alarm slaan als iets in zo'n certificaat "klinkt als DoH". Ik zie niet hoe dat eenvoudiger zou zijn dan te proberen een blacklist met IP-adressen van known DoH servers up-to-date te houden.
Niet als op het netwerkverkeer DoH-verkeer als zodanig te herkennen is,
en volgens mij is het dat. Het is namelijk te zien aan aan het content-type ("application/dns-message" o.i.d. ) dat m.b.v. een byte in het netwerkverkeer wordt aangegeven. (nl. in de eerste byte van de TLS-portie, voor zover ik heb kunnen zien is dit bij https normaalgesproken byte no.36(hex), dus de 54-ste byte).
Zie hiervoor
https://akhila12ca.wordpress.com/2013/03/27/capturing-the-ssl-packets-using-wireshark/:
Each of the SSL records begins with the same three fields (with possibly different values).
One of these fields is “content type” and has length of one byte. List all three fields and their lengths.
Three fields in Record protocol are:
Content type - 1 byte
Version - 2 bytes
Length - 2 bytes
Door Anoniem: (certificaat-informatie wordt niet meeversleuteld bij https, en dat weet jij heel goed he Erik?)
Vanaf TLS v1.3 kunnen (of zullen? ik weet heus niet alles) certificaten pas worden uitgewisseld als de verbinding is versleuteld.
Ok, ik wist dat jij het er in het verleden eens over had gehad dat certificaatinformatie leesbaar was.
Als dit met TLS1.3 niet meer het geval is, heeft DoH weer iets meer privacywaarde dan ik dacht, hoewel het IP-adres van waar je heen gaat natuurlijk nog wel steeds zichtbaar is.
Dit is dan ook exact de reden dat het veelgenoemde voordeel van DoH, nl. dat het jouw privacy zou waarborgen, niet klopt.
Ik had al eerder aangeduid dat ik dat meer een "marketing stunt" vind, en het security aspect belangrijker vind.
Door Anoniem: DoH is dus vooral een security bescherming, die ons eindelijk kan beschermen tegen manipuleren van DNS-informatie op de lijn waarmee een MITM je naar een site zou kunnen sturen die malware serveert.
Om
dat risico uit te sluiten is, lang geleden, https al uitgevonden [*], waarvan het gebruik t.o.v. http de afgelopen jaren enorm is gegroeid. Als een rogue DNS server jou naar een webserver in Rusland stuurt als jij
https://mijn.ing.nl/ opent in jouw browser, krijg je een certificaatwaarschuwing (tenzij die server over een kopie van de private key van mijn.ing.nl beschikt, of als de eigenaar van die nepwebserver een -door jouw brouwser vertrouwd- certificaat voor mijn.ing.nl heeft weten te verkrijgen).
Dit is absoluut niet het geval als men start met http i.p.v. https. Er zullen altijd leken blijven die dit doen,
vooral als ze zien dat ze toch wel automatisch op https terechtkomen. (redirect)