Heel goede informatie! Het blijft me evenwel verbazen dat de browsermakers zo op ramkoers met de netwerkbeheerders
zijn gegaan. Het bekende "de overheid of je ISP spioneert op je" verhaaltje is gebruikt om legitieme acties van lokale
DNS resolvers de nek om te draaien en brengen nu de beheerders in de problemen. Wat een wereld.

Dat is vooral ingegeven door de Amerikaanse netwerk beheerders die rommelen met DNS antwoorden om onder andere reclame te injecteren, en resultaten van DNS lookups verkopen. Zo gek is het dus niet. Comcast c.s. zijn niet echt de braafste jongetjes van de klas in tegenstelling tot xs4all (althans nog wel).

Ik lees in de voorlaatste link dat het eerste botnet al aangetroffen is die DoH gebruikt om zijn CC te bereiken. Op die manier wordt detectie van het botnet bemoeilijkt.

Ik heb zelf ook het gevoel dat kwaadwillenden meer profiteren van dit soort encryptie dan de goeden die je wilt beschermen. Per saldo is het dan een achteruitgang van alle goedwillenden in het algemeen.

DNS resolve levert een IP-adres op, en op IP-adres kan men bijna net zo goed filteren en monitoren als DNS.

Deze discussie is daarom niet veel anders dan in een situatie waar men gewend is om te monitoren wie met wie belt
te gaan zeuren: "och wat vreselijk, nu kunnen wij de namen van de personen zoals ze in de telefoongids staan
niet meer loggen, filteren of controleren", want we kunnen alleen nog maar de telefoonnummers zien.
En dat is natuurlijk BS. Want die namen zijn direct met de telefoonnummers gerelateerd.

Evenzo zijn IP-adressen gerelateerd aan domeinen.
Dus ze zouden simpelweg kunnen overschakelen naar het monitoren/filteren van IP-adressen i.p.v. DNS.
Bijv. bij de eerste SYN naar het IP-adres dat men wil bezoeken, dus bij de eerste stap van het leggen van de verbinding.
(of desnoods automatiseert men reverse DNS van IP-adressen naar domeinen)

Het wordt alleen onduidelijker in geval er meerdere niet met elkaar gerelateerde domeinen achter hetzelfde IP-adres schuilen. Maar ach, ook met DNS was het al niet perfect, want men kan daarmee niet zien naar welke pagina je precies gaat. Dus hoe erg is dat? Is het eigenlijk niet "heel GDPR" dat alles niets zomaar haarfijn kan worden gepinpoint?


Het voordeel van DoH is overigens dat een MITM je niet meer gemakkelijk naar een louche IP-adres kan sturen door DNS aan te passen. Met al die brakke routers die er nog altijd staan.... (waarop oplichters geregeld de ingestelde dns-servers kunnen aanpassen, zodat gebruikers worden omgeleid naar malware)
En dan is het een hele verbetering om te mogen beschikken over DoH.

Maar wel naar welke site en dat kan nu ook niet meer. Zeker omdat vrijwel niemand meer de moeite neemt om reverse
DNS in te richten tegenwoordig. Als iemand een connectie maakt met een bepaald IP adres poort 443 weet je niks.

Als je van de baas de opdracht krijgt om Youtube te blokkeren tijdens kantoortijd dan kon je dat nog regelen door in je
lokale DNS resolver de Youtube domeinen te blokkeren (en te zorgen dat poort 53 altijd naar de lokale resolver gaat).
Nu kan dat niet meer want je gebruikers zeilen er gewoon omheen met DoH.
Nu kun je natuurlijk roepen "dan moet je als baas maar niet willen dat je medewerkers bepaalde sites niet kunnen bezoeken" maar dat is soms gewoon nodig. En ook gewoon rechtmatig.

Zelfs deze info gebruiken om verschillende categorieen sites een verschillende prioriteit of bandbreedte te geven dat
gaat straks niet meer. Daarmee worden de serieuze medewerkers straks getroffen door het wangedrag van degenen
die het beleid niet respecteren. Geen vooruitgang.

En dan hebben we het nog niet eens over split DNS. Of over het detecteren van malware.
Ik vind de zorgen in dat 1e document heel terecht.

Dat zelfde wordt / werd van https gezegd, ook maar mee stoppen?

Oh het forceren van https heeft zeker een hoop kwaad gedaan ja. Gewoon de keuze vrij laten zonder rare druk vanuit
browser en zoekmachine bouwers was beter geweest.

Cloudflare is wel de laatste partij waar mijn data veilig is. Ze helpen zelf grote aantallen criminele klanten en ze gedragen zich als een dictator en manipulator. O.a. met idiote captcha's die niet op te lossen zijn en door RFC's te maken die slaan als een tang op een varken en alleen hun eigen probleem oplossen en anderen opzadelt met een ander probleem.

DoH kan worden uitgezet via about:config door network.trr.mode op 5 te zetten.

Let op: als je dat doet op de laatste ESR versie werkt het resolven via proxy helemaal niet meer!

Mozilla is enorm traag in het oplossen van bugs. Als ze eindelijk worden opgelost is de kans op nieuwe bugs groot. Het lijkt erop dat testen niet hun sterkste kant is.

Oh, en hoe zie jij introductie van HTTPS zonder enige kans op misbruik dan voor je?

Zonder die druk was een veel groter deel van verkeer nog steeds HTTP. En makkelijker om daar mee te rommelen en misbruik te maken. Maar de oplossing daarvoor is geen HTTP gebruiken zeker?

Zo kun je doorgaan, vrijwel elke nieuwe technologie kan ook misbruikt worden. Ze maar verbieden is geen oplossing en regulieren heeft ook nooit gewerkt, dus wat dan?

Je geeft zelf al aan waarom het filteren op IP moeilijker wordt dan het filteren op domein.
Het komt steeds vaker voor dat er gebruik gemaakt wordt van meerdere domeinen op 1 IP (cloudflare, OVH SAS, Amazon etc.).

In plaats van gebruik te maken van DNS over HTTPS zou men in mijn optiek beter gebruik kunnen maken van DNS-SEC dat werkt met certificaten (zoals een PKI). Helaas wordt dit (nog) niet door elke site gebruikt.

Dat is absoluut niet het geval. DNS is veel gemakkelijk en sneller te managen. Bedrijven hebben soms centrale DNS en local Internet Access.
IP adressen kunnen veel sneller veranderen dan firewalls geupdate kunnen worden. Terwijl het DNS record het zelfde blijft.

Het is technisch ook mogelijk, maar veel complexer. Persoonlijk vind ik DOH een slechte oplossing. Het bijpast veel te veel waardoor het onveiliger is/wordt.

Reverse DNS... Dat werkt voor heen meter mocht je dat nog niet door hebben. Daarnaast een DNS record veranderd niet, een IP adres wel.En kan icm CDN ook nog een dynamisch zijn en door meerdere diensten gebruikt.

Ook zeker niet perfect inderdaad, maar wel beheers en controleerbaar

Best wel groot. Heb jij toevallig geen ervaringen in grote organisaties? We blokkeren hier eigenlijk het DOH op alle firewalls. Maar het is verdomde lastig bij te houden.

[quote[Het voordeel van DoH is overigens dat een MITM je niet meer gemakkelijk naar een louche IP-adres kan sturen door DNS aan te passen. Met al die brakke routers die er nog altijd staan.... (waarop oplichters geregeld de ingestelde dns-servers kunnen aanpassen, zodat gebruikers worden omgeleid naar malware)
En dan is het een hele verbetering om te mogen beschikken over DoH.[/quote]Op je router inderdaad niet, maar Firefox heeft al de mogelijkheid om een custom DOH in te vullen. Dus kan nog steeds vrij gemakkelijk gemanipuleerd worden.

Ik ken trouwens ook maar vrij weinig brakke routers die echt geïnfecteerd zijn.

DNSSEC heeft een heel ander doel, namelijk bescherming tegen DNS hijacken. Bij DNSSEC kun je vertrouwen op het antwword. het versleuteld het verkeer niet, anders dan DoH.

https://www.eurodns.com/blog/dns-over-https-dns-privacy

Dat is wel degelijk een probleem, zie [1] (4,5 miljoen routers in 2012), [2] (2018: 200.000) en mijn reactie in [3] (2019: 180.000), allen betreffende modem/routers in alleen al Brazilië. Overigens zijn die in een deel van de gevallen niet "geïnfecteerd", maar zijn de DNS-server instellingen er in gewijzigd middels een CSRF (Cross-Site Request Forgery) attack.

Ik pleit niet voor algemene inzet van DoH (integendeel), maar dit is an sich wel een goed en geldig argument in situaties waar dit risico hoog is. Aan de andere kant is DoH niet de enige oplossing voor dit probleem.

[1] https://www.security.nl/posting/38247/4%2C5+miljoen+ADSL-modems+in+Brazili%C3%AB+gehackt
[2] https://www.zdnet.com/article/mikrotik-routers-enslaved-in-massive-coinhive-cryptojacking-campaign/
[3] https://www.security.nl/posting/624120/EFF+roept+providers+op+om+DNS-over-HTTPS+te+ondersteunen#posting624186

5 a 10 milliseconden per request? Dat is volgens mij niet veel slechter dan een straight DNS look-up.
https://stackoverflow.com/questions/23943103/speed-up-reverse-dns-lookups-for-large-batch-of-ips

We zitten nu nog grotendeels op IPv4, en IPv4 kent een tekort aan IP-adressen.
Dit is de belangrijkste reden dat er achter 1 IP-adres soms meerdere totaal verschillende domeinen kunnen schuilgaan.
(hetzelfde heb je met telefoonnummers: er gaan soms meerdere gezinnen schuil achter één telefoonummer)
Maar de oplossing om ieder domein weer zijn eigen IP-adres te kunnen geven is er al een tijdje: IPv6.
1 + 1 = 2, dat hoef ik je niet voor te rekenen.

Dus ja, er zijn nog een aantal problemen die opgelost moeten worden en waarvoor men in beweging zal moeten komen.
Als onze (voor)ouders na WOII niet de schouders eronder hadden gezet om weer een welvarend bestaan op te bouwen
dan hadden jij en ik er nu niet zo warmpjes bij gezeten. Maar ook daar zat voortdurend beweging in, en reken maar dat
dat inspanning heeft gekost. Men blijft nu eenmaal niet eeuwig bij het oude als er iets beters voorhanden is.

DoH heeft heus zin. De vraag waar het nu nog om gaat (aan iedereen) is: jij ook?...

Daar is je firewall alleen niet voor bedoelt. Nog afgezien er gerust 10 dns requests per webpagina noodzakelijk moeten zijn.
En reverselookup werkt vaak niet goed.

Is dus geen betrouwbare oplossing.

Zou er misschien ook mee te maken kunnen hebben, dat de meeste hosters toch echt nog maar 1 IPv6 adres koppelen aan hun webserver.
Reken is dus niet noodzakelijk, want het lost niets op.

Het mag wel zin hebben, maar de implementaties hoeven geen verbetering te zijn of af te zijn. Voorbeelden genoeg sinds onze voorouders.

Heb je er geen zin in, dan hou je de ogen dicht en clamp je je vast aan de huidige status quo, en krijg je niks voor mekaar.

Heb je er zin in, dan sla je met gelijkgestemden de handen ineen, nagel je jezelf niet vast aan een status quo maar versta je "de kunst van het loslaten", en dus bedenk je met een open mind soms onconventionele oplossingen
en heb je het al voor elkaar voordat je het weet.

https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticism

Het laatste woord is er nog niet over gesproken.

De zeer ervaren journalist (vooral op gebied van cybersecurity) Catalin Cimpanu van ZDNet geeft in een vandaag verschenen artikel een m.i. uitstekend overzicht van de nadelen van DoH: https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/.

Zeer ongewenst dit DoH. Liever DoT want dan kun je nu al ook andere dingen dan browsers beveiligen. Ik ben alleen bang dat er helaas al teveel DoH is in het veld. Cloudflare wordt machtig. Willen we dit?

De Firefox implementatie van DoH heeft wel een backdoor die DoH uitzet op een geprepareerde lokale DNS resolver. Op de Mozilla site wordt het bij de werking van DoH uitgelegd hoe dit uit te zetten is. Effectief komt het er op neer dat je een speciaal domein moet toevoegen zonder A en AAA record. Of zorg ervoor dat dat domein een nxdomain als antwoord geeft.

Dat werkt goed. Ook als ik DoH expliciet aanzet in Firefox gebruikt hij het niet. Zolang Firefox deze achterdeur er in laat zitten, kan een systeembeheerder het via de lokale dns server binnen zijn netwerk uitzetten. Mozilla schrijft dat deze backdoor een tijdelijke oplossing is en dat ze zoeken naar een nettere methode. Maar de intentie blijft dat het uitschakelbaar blijft bij een locale DNS resolver. Dat moet ook wel anders brengt hij een heel intranet om zeep.

Zoals ik al schreef, het wordt ingegeven door de Amerikaanse netwerkbeheerders. https://tech.slashdot.org/story/19/10/06/2357249/big-isps-worry-dns-over-https-could-stop-monitoring-and-modifying-of-dns-queries

Voor de privacy is het mooi. Voor network security monitoring minder. Denk bijvoorbeeld aan het traceren van malware verkeer op een netwerk.

Het zou wel handig zijn als een of andere organisatie een "DNS blocklist" zou bijhouden voor DoH servers.
(een of andere DNS naam die resolved naar de IP adressen van publieke DoH servers)
Dan kun je gemakkelijk iets doen met verkeer naar deze servers (blokkeren, loggen, wat je wilt) zonder dat
je zelf moet bijhouden wat vandaag weer de adressen van de servers zijn.
Bestaat zo iets al?

Uit: https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/:
Geen enkele reden dus om er overspannen negatief over te doen.

Ja.

Ik ken meerdere rederen om (niet overspannen maar wel) negatief te doen, waaronder:

1) Wellicht is het nu nog mogelijk voor beheerders om Firefox te vragen niet van DoH gebruik te maken, maar Mozilla heeft aangegeven zich het recht voor te behouden om mogelijkheden daarvoor in de toekomst te schrappen;

2) Er is al malware gespot die van DoH gebruik maakt juist omdat organisaties dan minder kans hebben om te detecteren dat, nadat er per ongeluk een "trojan downloader" is gestart (zoals een Word file met macro), daadwerkelijke malware wordt gedownload en/of met C&C servers wordt gecommuniceerd. Er gaat ongetwijfeld meer malware komen die dit doet;

3) Nog weinig DoH servers betekent een concentratie van informatie, macht en afhankelijkheid van een klein aantal partijen waar je nauwelijks of geen invloed op kunt uitoefenen (dus commerciële internetbedrijven die een "gratis" dienst leveren waar ze een dikke infrastructuur voor nodig hebben - als je nu nog niet weet wat daar meestal de consequenties van zijn, heb je onder een steen geleefd). De druk en verleiding op (evt. individuele werknemers van) DoH leveranciers om informatie te verkopen zal toenemen (niet lineair vermoed ik) met het aantal gebruikers;

4) Het ligt voor de hand dat zo'n DoH leverancier op een gegeven moment gaat censureren (bijv. NXDOMAIN terugmelden bij lookups van bekende C&C servers). Maar dan begeeft die provider zich op een hellend vlak en krijg je ongetwijfeld te maken met false positives. Sommige overheden zullen binnen de kortste keren van die DoH provider eisen dat zij ook NXDOMAIN teruggeven voor websites van dissidenten, homo's, euthanasie, abortus, porno etc. E.e.a. kan natuurlijk ook worden beïnvloed door de denkbeelden van de eigenaren van die DoH-leverancier op dat moment. Daarnaast kan zo'n DoH-leverancier marktpartijen benadelen door de latency van lookups daarvoor te verhogen;

5) Er zullen wellicht meer partijen komen die geld ruiken door DoH servers op te tuigen, wat kan helpen tegen de concentratie genoemd onder punt 3. Dat maakt het weer lastiger voor organisaties om alle DoH servers te blokkeren, wat punt 2 verder in de hand werkt. Aan de andere kant, zie ook het volgende punt;

6) Om low-latency DNS diensten aan geografisch grote gebieden te kunnen leveren, heb je al gauw een CDN-achtig netwerk van servers in veel datacentra nodig, en er zijn maar weinig partijen die daarover beschikken. Het risico is dan ook dat je de beschikbaarheid van het hele DNS-systeem, dat nu gedistribueerd belegd is bij (en gecached wordt door) zeer veel partijen, afhankelijk maakt van enkele partijen. Dat Mozilla standaard voor Cloudflare kiest (overigens een partij met nu al griezelig veel macht vanwege hun uitgebreide CDN), vergroot dit probleem;

7) Zodra DoH ook maar een klein beetje een "succes" wordt, zal begonnen worden met het afbreken van de huidige DNS infrastructuur. Als DoH toch niet zo'n goed idee blijkt, wordt naar die oude infra teruggaan steeds lastiger en duurder.

Ik word een beetje moe van kortzichtige thuisgebruikers die roepen dat er geen probleem is, terwijl specialisten als Paul Vixie DoH een slecht idee vinden en ze eerdere reacties hierop in deze en andere threads niet eerst lezen. Lees in elk geval eerst https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/ eens en kom dan met argumenten waarom die experts geen gelijk zouden hebben.

Edit: nummering klopte niet.

Geloof er niks van dat ze dit doen als dit grote problemen blijft geven die niet op een redelijke manier kunnen worden opgelost.

Men kan op alternatieve manier zo nagaan met welke IPs er verbinding wordt gemaakt en deze blokkeren,
hetzij lokaal, hetzij bij de DoH-provider. Filteren is niet onmogelijk met DoH. Het werkt alleen net even anders als met DNS.

Het privacy contract dat Mozilla met Cloudflare heeft afgesproken m.b.t. DoH vind je hier: https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/
Al dat gezeur over Cloudflare elke keer: het is geen verplichte DoH-provider maar men moet ergens beginnen en een default hebben. Daarbij moedigt Mozilla nieuwe DoH providers aan. Het is zelfs mogelijk om je eigen DoH server op te zetten.
Daarbij: ook met DNS is er concentratie van informatie die voor meer ogen te onderscheppen is.

Te suggestief + zie ook antwoord 3) + dit zou met je DNS provider ook kunnen.

Zie antwoord 1)

Wat als je eigen internetprovider over enkele jaren DoH levert? Maar alles kost tijd natuurlijk, en ondertussen moet je wat.

Er is geen leven of vooruitgang zonder risico's.

Ik wordt een beetje moe van al die Decepticons die maar met hun blote ervaren voeten in de hedendaagse klei blijven staan,
en van daaruit al met hun oordeel klaar staan. Ja, er zijn voor en nadelen, en vanuit privacy-oogpunt is het wellicht wat overgewaardeerd (of noem het een marketingstunt) maar het naakte DNS is ten eerste kwetsbaar en zet ten tweede gelegenheidsgluurders te kijk. En de gelegenheid maakt de dief. Dat is een ding wat zeker is. Wil jij dát dan?

Mozilla heeft zelf ook allang toegegeven dat er nog problemen zullen moeten worden overwonnen voordat er van een succes kan worden gesproken. Die hebben heus wel oog voor de problemen en zullen geen grote groepen met echt hele serieuze problemen voor het blok zetten.

O wacht, jij (anoniem, reputatie?) hebt gelijk en al die experts hebben het fout.

Dat je DNS-servers wilt authenticeren en de verbinding ermee wilt versleutelen vind ik prima, maar gebruik dan DoT.

Ik wil jou wel eens op alternatieve manier zien nagaan waar er DoH gebruikt wordt!
Denk je echt dat je een patroon zult kunnen vinden in de poort 443 connecties die er vanaf een netwerk gemaakt worden
en daar de DoH tussen uit vissen?
Nog even en er worden ALLEEN MAAR poort 443 connecties gemaakt vanuit het gemiddelde netwerk.

En bij gebrek aan een handige list van DoH servers (we zullen het gevatte antwoord van 7-10 21:42 maar even negeren)
heb je helemaal geen idee wie er DoH gebruikt.

Wie heeft er gesproken over DoH eruit vissen dan??? Het DoH-deel is immers in zichzelf nog niet kwaadaardig, dus waarom zou dat moeten? Blijkbaar denk je weer zoals het met DNS nu werkt? Volgens welke wet MOET het met DoH allemaal precies zo werken? Dat is maar een aanname van je. Als je van bromfiets naar auto gaat zit er opeens geen gashendel meer aan je stuur, maar doe je dit met je voet. Op een andere manier dus. Als iets niet op de oude manier kan zoals je gewend was, dan lijkt het me logischer om er eens wat dieper over na te denken hoe het dan misschien wél zou kunnen. Dát is de challenge waar we met Mozilla momenteel voor staan. (als je die tenminste aan wilt/kunt gaan)

Je zei dat filteren niet onmogelijk was. Maar dat is het dus WEL. Want je geeft al aan dat je het verkeer niet eens
kunt identificeren, laat staan filteren.
Als je van bromfiets naar auto gaat moet je wel het stuk karton dat je op de voorruit legt imv sneeuw weghalen voor
je gaat rijden anders zie je niets. En met DoH ook niet.

Ooit gehoord van Bluecoat? Ooit gehoord van SSL breken? Het is niet eens moeilijk of ingewikkeld. Je kunt zelfs specifiek op DoH filteren.

Dat komt omdat jij nog steeds in je hoofd hebt dat je moet filteren zoals je m.b.v. DNS filterde. En dat kan inderdaad niet.
Dus zul je op andere manier moeten filteren om te voorkomen dat de verbinding met het rogue IP-adres daadwerkelijk wordt gestart. En dan komt het aan op precieze kennis en op hoe vindingrijk men is, maar ik zie zo al 2 mogelijkheden.

Naast een knap lastige oplossing die ik beschreef in https://www.security.nl/posting/626516/NCSC%3A+DoH+en+DoT+maken+dns-monitoring+moeilijker#posting626599, ken ik er zelfs nóg 3:

1) Blokkeer alle verkeer met internet en zeg dat medewerkers hun BYOD via 4G moeten gebruiken als ze willen internetten;

2) Installeer software op alle PC's die de gebruikte CSPRNG's beïnvloedt, waarna je het TLS verkeer eenvoudig kunt decrypten (meer info: https://www.bleepingcomputer.com/news/security/hackers-patch-web-browsers-to-track-encrypted-traffic/);

3) Of, zoals Anoniem van 19:48 hierboven al aangaf, zet poort 443 naar internet dicht en forceer zo het gebruik van een TLS MitM proxy, en installeer het bijbehorende rootcertificaat als trusted door Windows (Mozilla zag dit al aankomen, zie https://www.security.nl/posting/615285/Firefox+verhelpt+tls-foutmelding+die+antivirus+veroorzaakt).

Ik verwacht dat veel bedrijven, dankzij DoH, alsnog voor optie 3 zullen kiezen (en dat landen, zoals Kazachstan, weer een extra excuus hebben om toch/weer te gaan MitM-en). Behalve dat daarmee DNS gefilterd kan worden, kunnen foute beheerders (of inbrekers op zo'n device) kijken hoeveel geld collega's (of de baas) op hun bankrekening hebben als ze, vanaf hun werk-PC, internetbankieren. Of -OMG!!- jouw security.nl wachtwoord afkijken (oh nee, wacht, je post anoniem). En helaas introduceer je er nog een heleboel onveiligheden mee, zoals veel tests van dat soort producten tot nu toe uitwezen (zie bijv. https://www.us-cert.gov/ncas/alerts/TA17-075A).

Allemaal "oplossingen" die een weldenkend mens niet wil dus. Daarom zijn we extreem benieuwd naar jouw "2 mogelijkheden". Laat je ons niet te lang in spanning?

Dit zijn allemaal oplossingen die niet werken op een bedrijfs Wifi-gastnetwerk waar de mensen gewoon hun eigen telefoon
en tablet aan kunnen connecten.
Als je de systemen in beheer hebt dan is het hele probleem er niet want dan kun je gewoon de juiste policy settings maken
waardoor DoH uitgeschakeld is. Het gaat juist om de niet gemanagede systemen.

DoH zorgt alleen maar voor toegevoegde lekken.
Dat is het grootste bezwaar.
#sockpuppet

Ik zal 1 optie verklappen die al bestaat: een DoH -service die voor security filtert.
Doet je browser een DoH lookup-request en is bij de DoH-provider reeds bekend dat het daar foute boel is, dan gaat het feest niet door. Voorbeeld: https://cleanbrowsing.org/guides/dnsoverhttps Security Filter.
Met een dergelijk filter voor zover dit redelijk actueel wordt gehouden heb je het gros van de ellende al te pakken.

Dit heeft NIKS met DoH te maken, dat soort services bestaat al jaren voor gewone DNS lookups. Je stelt gewoon hun
recursive resolver in en klaar.

En de privacyverklaring van Twitter vind je hier: https://twitter.com/en/privacy. "Onbedoeld" mijn derrière: https://nos.nl/artikel/2305328-twitter-gaf-onbedoeld-telefoonnummers-en-mailadressen-aan-adverteerders.html en https://www.security.nl/posting/627063/Twitter+gebruikte+2FA-telefoonnummers+voor+advertenties. Als iets gratis is, is inbreuk op jouw privacy meestal het verdienmodel.

En daar trekt reeds draaiende malware zich wat precies van aan?

En daar trekt reeds draaiende malware zich wat precies van aan?

Als iemand die dagelijks primair met op Debian gebaseerde systemen werkt vind ik dat iets te kort door de bocht. Het wantrouwen is meer op zijn plaats voor bedrijven die duidelijk goed verdienen aan dingen die ze gratis lijken weg te geven dan voor gratis in het algemeen. Maar wat je meestal tegenkomt kan van persoon tot persoon verschillen, natuurlijk.

Bij een bedrijf dat wel zo'n verdienmodel heeft zie ik trouwens nog wel andere mogelijkheden die het mis kunnen doen gaan. In het algemeen geldt dat in een systeem waar achteraf eisen aan worden toegevoegd de implementatie daarvan vaak lapwerk is, omdat de nieuwe eisen vaak genoeg conflicteren met het oorspronkelijke ontwerp en niet voor een totaal herontwerp wordt gekozen maar voor veel kleinere aanpassingen — die dus niet goed passen. Als oorspronkelijk geen privacy by design is toegepast kunnen aanpassingen op dat vlak gebreken vertonen, zelfs als ze goed bedoeld zijn, en dat is ook een bron van dit soort ongelukken.

Zelfs bij het ultieme voorbeeld van een bedrijf met zo'n verdienmodel, Facebook, heb ik al een paar keer gedacht dat de zoveelste privacyblunder te knullig was om doelbewust te zijn in een tijd van de AVG en inmiddels ook de Californische privacywet. Ik vermoed dan eerder dat het "move fast and break things"-ontwikkelmodel dat ze daar formeel hebben afgeschaft in de praktijk nog volop wordt gehanteerd. Het is wat die organisatie en de ontwikkelaars door en door gewend zijn om te doen; een cultuuromslag is een kwestie van zeer lange adem. Ik vertrouw Facebook voor geen cent, maar tegelijk lijkt het me waarschijnlijk dat daar dingen mis gaan die ze helemaal niet doelbewust verkeerd doen, domweg door de manier waarop ze gewend zijn te werken en het algemene onvermogen van groepen mensen om zoiets snel te veranderen.

Cloudflare heeft op zich een verdienmodel waarbij klanten betalen, in de vorm van een gratis basis om gebruikers binnen te halen en betaling voor verdergaande diensten. Ik weet niet hoe goed dat voor ze werkt, maar als het werkt is het goed denkbaar dat ze dit gratis kunnen aanbieden zonder noodzaak het te exploiteren op de manier waarop sociale media-bedrijven dat doen. Het past zelfs in hun manier van werken. Ik weet echt niet zeker dat ik ze kan vertrouwen, maar ik weet ook niet zo zeker dat ze niet te vertrouwen zijn als ik dat van Facebook weet.

En daar trekt reeds draaiende malware zich wat precies van aan?

- Ten eerste: "het gros van de problemen" is niet hetzelfde als "alle problemen".
Dat met DNS al sinds jaren voor een security-filter gekozen kan worden, doet er niets aan af dat het kan.
Alleen ik constateer dat het voor DoH des te nuttiger kan zijn dat een dergelijke service "de default" gaat worden voor DoH providers. Of dit wel of niet mogelijk is, is niet aan ons om te onderzoeken of te beoordelen. Ik constateer alleen maar.

- Als je reeds draaiende malware hebt, kan een rogue DNS-domein net zo weinigzeggend zijn als een IP-adres.
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. (certificaat-informatie wordt niet meeversleuteld bij https, en dat weet jij heel goed he Erik?)
Dit betekent overigens tegelijk dat de toegenomen privacy met DoH maar beperkt is,
want aan de certificaat-informatie die plain op de lijn staat, is nog steeds te zien welke websites men met https bezoekt.
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.

Overigens is DoH.-verkeer herkenbaar aan byte nummer hex 36 waarmee het MIME-type wordt aangegeven.
Met een tool filter je deze netwerkpakketten er zo uit, en kan je zien bij welk IP ze vandaan komen en naar welk IP ze toe gaan.
Allemaal niet zo moeilijk, maar als men geen zin heeft om het uit te zoeken wordt er alleen maar deceptie geblért.

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.

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.

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.

Omdat C&C-server-domeinnamen een langere levensduur hebben, zijn ze als IoC (Indicator of Compromise) vaak interessanter dan IP-adressen. Beide zijn overigens interessant, maar door DoH verliezen organisaties (die geen TLS-inspectie doen) het zicht op C&C-server-domeinnamen.

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.

Vanaf TLS v1.3 kunnen (of zullen? ik weet heus niet alles) certificaten pas worden uitgewisseld als de verbinding is versleuteld.

Dat certificaat vervalt met TLS v1.3, maar het IP-adres van de server waar je mee communiceert is nog steeds te zien. Dit is dan ook exact de reden dat het veelgenoemde voordeel van DoH, nl. dat het jouw privacy zou waarborgen, niet klopt.

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). Daarnaast, dat je met DoH via een beveiligde verbinding met een DNS server communiceert, betekent niet dat die DNS server ook automatisch betrouwbare informatie levert (de beheerder kan onbetrouwbaar blijken of die DNS server kan valse informatie hebben ontvangen en doorgeven).

[*] En als https niet veilig zou zijn, is DNS over https dat natuurlijk ook niet.

Ofwel je hebt zojuist iets speciaals gerookt, ofwel ik heb iets essentieels van DoH gemist/over het hoofd gezien. Heb je een referentie met meer info over dat "hex 36 MIME type" (dat, om interessant te kunnen zijn -mocht zoiets bestaan-, natuurlijk niet https-encrypted moet worden verzonden)?

PS ik geloof niet dat we uit deze discussie gaan komen. De kans bestaat dat ik niet verder reageer op anonieme bijdragen in deze thread.

@Anoniem vandaag 12:22:
1) Cloudflare is een commercieel bedrijf en zo'n DoH infrastructuur onderhouden kost geld. Geld dat aandeelhouders liever in hun zak steken, tenzij Cloudflare hen ervan kan overtuigen dat er een business case voor bestaat. Ik sluit niet uit dat Cloudflare op een "privacy-vriendelijke" manier hun investeringen kan compenseren, maar mijn ervaring is dat bedrijven het dan al snel hebben over "geanonimiseerde gegevens" die, zoals later vaak blijkt, gedeanonimiseerd kunnen worden;

2) Grote verzamelingen informatie zijn nou eenmaal geld waard. Ook als het bedrijf Cloudflare die gegevens (of een deel daarvan) niet verkoopt, is de verleiding voor individuele of groepjes werknemers groot.

En nee, dit is geen bewijs dat het fout zal gaan. Maar als je het cyberbeveiligingsnieuws op security.nl een paar jaar gevolgd hebt, moet je wel heel positief zijn om het risico op privacyschendingen door grote DoH aanbieders laag in te schatten.

Nou, niks, op dit moment kun je nog naar de SNI kijken, maar op lange termijn waarschijnlijk niet meer.

Want Encrypted SNI is de stap naar encrypted DNS.

Als organisaties moeten filteren, moet je gewoon zorgen dat gebruikers verplicht door een HTTP-proxy gaan.

Geen transparante onzin, geen providers die DNS omleiden, antwoorden vervalsen, etc. Geen impliciet, maar expliciet. Gebruikers in organisaties vertellen wat er aan de hand is en daarmee basta.

Geen batch collection van data op provider netwerken, geen advertenties injection op HTTP, etc. en dus geen privacy probleem.

Ik ben anoniempje van optie 3, als men even kort wil internet bankieren, dan moet men dat maar op de telefoon doen.

De rest van de tijd, lijkt mij beter dan men op het werk gewoon aan het werk is.

Blijkbaar geen ervaring in grote organisaties? Of beheerde werkplekken, of security?

Veel trager, en complexer en veel lastiger te detecteren.

Nog lastiger voor vanuit security.

Waarom iets veranderen wat goed werkt. DNS over DNS. Daarnaast zijn er voldoende overige maatregelen die wel goed werken, zonder al deze issues, namelijk: DOT.


Tja dat dachten we ook over asbest. Achteraf toch niet zo goed idee.

Er zijn opstart problemen, er is iets mis vanuit het de geachte...
Daarnaast lost het ook weinig op. Als je DNS server compimised is, en verkeerde informatie aanlevert, maakt DNS vs DOH niets uit hierin.
Het Internet is alleen een stuk onveiliger geworden met deze oplossing.

Het zijn geen problemen, maar gewoon architectuur issues. Ze willen iets oplossen, waar betere alternatieven voor zijn, namelijk DOT.

Je weet dat malware ook al via DNS requests opdrachten kan krijgen en uitvoeren? Detectie is in eens een stuk lastiger geworden hiervan. Voor bedrijven een serieus probleem.

Je weet dat je gewoon MitM attacks op https verkeer kan uitvoeren. Wordt hier ook gewoon gedaan door ons bedrijf. Al het https verkeer wordt gewoon geanalyseerd en kan dus tegen gehouden worden.

Daar heb je dan vast een bron van, want ik kon niets vinden op het Internet.
Idem bij alle grote firewall leveranciers.

Blijkbaar heb jij iets gevonden, wat de rest van de wereld nog niet weet. So please share......

Blijkbaar hebben alle grote firewall leveranciers dit "niet zo moeilijk puntje" over het hoofd gezien.

Eindconclusie meer "security through obscurity".
Het circus wordt steeds onoverzichtelijker.
#sockpuppet

Dat kan ALLEEN voor systemen die je zelf beheert! En daarbij is het hele probleem er niet want die kun je zo configureren
dat er geen DoT gebruikt wordt. Dat kan simpel met behulp van policies voor de betreffende programma's (Firefox) en
als dat niet meer kan kun je die programma's gewoon de-installeren en verbieden. Dat is dus geen issue.

Waar het om gaat is de eigen spullen die je niet beheert. (en die uiteraard op een apart subnet zitten)
Daar kun je NIET meekijken met https zonder de gebruikers te vragen hun spullen te verbouwen, wat uiteraard niet
realistisch is. Wellicht zou er een protocol moeten worden ontwikkeld waardoor bijv een WiFi hotspot pagina een
tijdelijk rootcertificaat kan aanbieden wat de gebruiker moet accepteren om in te kunnen loggen en wat dan voor de
duur van die sessie in het client device actief blijft, en daarna meteen weer verwijderd. Maar volgens mij bestaat dat
nog niet, in ieder geval niet breed over alle platformen.

Is geen requirement hoor. Of je krijgt alleen een certificaat error, of je moet zorgen dat de root CA geïmporteerd wordt door de gebruiker.

Hoeft ook niet zo te zijn. Als ik als gebruikt handmatig de root CA importeer, dan beheer jij helemaal niets op mijn machine.
Daarnaast hoe wil je dit met malware beheren? Die zeggen gewoon ignore certificate error.

Hangt er maar vanaf. Het betekend nog steeds dat je gewoon een heel groot probleem hebt voor je infrastructuur. Zelfs de vraag kan zijn, of managed devices wel met alle aanpassingen overweg kunnen.

]quote]Wellicht zou er een protocol moeten worden ontwikkeld waardoor bijv een WiFi hotspot pagina een
tijdelijk rootcertificaat kan aanbieden wat de gebruiker moet accepteren om in te kunnen loggen en wat dan voor de
duur van die sessie in het client device actief blijft, en daarna meteen weer verwijderd. Maar volgens mij bestaat dat
nog niet, in ieder geval niet breed over alle platformen.[/quote]Verdiep je even in was basic dingen van Privacy en Security, dan weet je ook meteen waarom dit niet bestaat en ook nooit zal komen.

Conclusie is: DOH is gewoon een heel slechte oplossing.

Kleine aanpassin gedaan.

Het is namelijk onveiliger geworden door obscurity en lost eigenlijk niets op, waar al een goede oplossing voor mogelijk was.

@anoniem van 14.38,
Daar zijn we het dan goed over eens. Er gebeurt meer direct buiten beeld, de toegevoegde veiligheid mag je in twijfel trekken. Zeker voor het product a.k.a. de eindgebruiker en het betekent nog meer inkomsten voor de partijen, die er toch al niet om verlegen zitten. Wat naijlt is een wat dubbel gevoel. Ik sta niet te juichen als website security consultant.
#sockpuppet

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.

Met DNS i.p.v. DoH wordt zo'n situatie er dus niet veel gemakkelijker op, want het lijkt een doodgewoon domein?...

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?...)

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/:


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.

Ik had al eerder aangeduid dat ik dat meer een "marketing stunt" vind, en het security aspect belangrijker vind.

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)

Gewaardeerde posters en lezers van deze draad,

Dit krijg je er kennelijk niet meer uit weg, CloudFlare samen met CloudFlare/Amazon,
die via een tweede IP spam rondpompen.

Even de technische feitjes - Cloud IP scan resultaten aangaande:
https://www.ip-adress.com/website/ksbshipyard.co.id willekeurig voorbeeld
Service die draait op deze server:
SF-Port53-TCP:V=7.70%I=7%D=10/11%Time=5D9F70E0%P=x86_64-onbekende-linux-gnu%
SF:r(DNSVersionBindReqTCP). bij -melinda.ns.cloudflare.com
draaiend op resolver SAN 53/tcp open domein (onbekende banner: 20171212);
zie: https://www.ip-adress.com/ip-address/ipv4/173.245.58.198
Zie verder : https://toolbar.netcraft.com/site_report?url=melinda.ns.cloudflare.com
-> https://mxtoolbox.com/SuperTool.aspx?action=a%3amelinda.ns.cloudflare.com&run=toolpage
Gegenereerd door cloudfront (CloudFront)
Request ID: i7NnYAjCZZrKzvh-nM21-W2JRbKLJ1IO6PzBNTZk8vI2b5JQKlVDyA==

Gecombineerd via de Amazon Organization, zie Amazon CloudFront op: server-70-132-49-82.lhr62.r.cloudfront.net
Netcraft risico score 7 rood uit een totaal van 10:
https://toolbar.netcraft.com/site_report?url=server-70-132-49-82.lhr62.r.cloudfront.net
geregistreed door adboer: markmonitor dot com. Geen matches werden gevonden bij Virus Total
voor genoemd IP 70.132.49.82 en dan komen we dus bij de crux van ons verhaal, namelijk het volgende spam rapport:
https://cleantalk.org/blacklists/70.132.49.82 volle spam rate bedraagt 19.04%

IP moet dus geblacklist worden en liefst geblokkeerd en daar zat het probleem al die tijd,
wordt in de zoekresultaten dus lekker weggehouden, bewijst onzekerheid door obscure resultaten.

Q.E.D. wat bewezen had moet worden, ergo conclusio, men spamt er lekker op los
en verwisselt adware lekker van de ene provider service jassend naar de andere provider service.
Herken de patronen en het verhaal wat enekelen al hier aanhaalden en weet dus wat er gebeurt ;)

luntrus

Het zal wel aan mij liggen, maar ik zie zo even niet duidelijk wat het ene met het andere te maken heeft,
en waarom je ze met elkaar "combineert"?

Wat is nu precies zonder omhalen de strekking van je verhaal?

1 domeinnaam met 2 IP adressen, waarvan op 1 wordt gespammed.
Spam-ip is van Amazon. Ik combineer niets. Als je dit niet kunt lezen of wil zien, is dat niet mijn probleem. Het is jouw probleem. Debunk anders de rol van CloudFlare en Amazon als advocaat van de duvel.

Maar welke domeinnaam bedoel je dan?
ksbshipyard.co.id kent meerdere IP adressen (2xIPv4 en 2xIPv6) en draait zo te zien via SNI bij Cloudflare.
(en bij ksbshipyard.co.id hoort géén IP 173.245.58.198)
SNI heeft overigens de bedoeling dat er ook nog andere servers met een andere domeinnaam hun toegang vinden via hetzelfde IP-adres.
Vervolgens komt zonder verklaring uit de lucht vallen dat van 173.245.58.198 (vermoedelijk een intern IP bij Cloudflare?)
volgens Netcraft geen dreiging uitgaat. MXtoolbox waarschuwt "DNS record not found". (logisch als het een interne server is)

Daarna schreef je: "Gecombineerd via de Amazon Organization....", en nou net zeg je weer: "ik combineer niets" ???

Vervolgens kwam je in je eerste bereicht met totaal iets anders (server-70-132-49-82.lhr62.r.cloudfront.net) waarvan je niet uitlegt hoe je daar nu weer aankomt, maar waarbij Netcraft dus gevaar aanduidt. (rood)
Sorry, maar ik zie niet wat dit te maken heeft met het er aan voorafgaande.
Uit jouw verhaal volgt niet wat het ene met het andere te maken heeft, en hoe je daar aan komt.
Het lijkt willekeurig uit de lucht gegrepen.

Kan iemand me vertellen waarom ik dit adres niet "rsolved" krijg.

Zie: https://toolbar.netcraft.com/site_report?url=222.11.20.104.in-addr.arpa
Zie: Info bron Fip.

#sockpuppet

Repeteer de antwoorden hier voor oorzaken van server failures:
https://www.coursehero.com/file/p531bkf/Whats-the-main-tool-for-resolving-DNS-problems-A-dnslookup-B-nslookup-C-ping-D/

Jodocus Oyevaer

Vaag verhaal (en wat onbegrijpelijk / leesbaar verhaar), maar belangrijker, wat heeft dit met DOH te maken? Ik zie de link of relatie hiermee nog niet.

Dus de toegevoegde discussie waarde is????

Of je zet iets neer wat niet te begrijpen is. En zo te zien zijn er meerdere die dit hebben.
Ikke niet snappen, en dat ligt echt niet aan deze poster.
Misschien had je gewoon je eigen topic hiervoor moeten aanmaken? Aangezien ik niets zie, dat dit ook maar iets met DOH te maken heeft.

Zeg luntrus, je verwart toch toevallig niet Cloudflare met Cloudfront he?
Cloudfront heeft niets met Cloudflare te maken. Cloudfront is van Amazon.

CloudFlare =OK & CloudFront/Amazon dns manipulatie op een van de ip's, niet publiek toegankelijk. Rol voor DoH hier?

Er zit wel degelijk een relatie met CloudFlare. CloudFlare, Google en Mozilla versus de rest van de globe,
maar met een daardoor moeilijker beheer en filtering.

Daarnaast de noodzakelijkheid die gevoeld wordt voor het implementeren van DNSSEC,
maar dat wordt op de infrastructuur nou net weer niet afgedwongen door deze grote spelers,
omdat hen dat minder goed uitkomt. Lees:
https://www.acunetix.com/blog/web-security-zone/doh-mozilla-cloudflare-google-vs-world/

Algemeen overzicht aangaande de voors en tegens van DoH, hier:
https://www.netsparker.com/blog/web-security/pros-cons-dns-over-https/

Het is overal dus nog lange na niet een ideale toestand, zie:
https://observatory.mozilla.org/analyze/doh.cleanbrowsing.org [B-status]

luntrus

Ik haal dit dit alleen nergens uit een post dat er DNS manipulatie gedaan wordt.

Dit suggereert dat de hele wereld tegen DoH (zoals gebracht door CF, Google en Mozilla) zou zijn, en dit is niet zo.
Het zijn ten eerste de producenten van softwarematige filters die moord en brand schreeuwen, omdat ze vrezen dat als DoH populair wordt hun goudmijn-filters bijna niet meer te verkopen zijn. Behalve misschien aan nog slechts een aantal DoH providers, maar die zijn veel minder in aantal dan consumenten. Dus inkomstenderving.
Hun gaat het in de eerste plaats ordinair om geld.
Daarnaast maken bedrijven zich zorgen die met hun poten in de hedendaagse kennisklei staan en zich niet realiseren dat deze klei voortdurend aan verandering onderhevig is, dus hun oordeel is prematuur. Mozilla gaat twee jaar de vinger aan de pols houden om verbeteringen en oplossingen te verzinnen waar dit nodig mocht zijn. Laten we dit a.u.b. afwachten.

Uit https://www.acunetix.com/blog/web-security-zone/doh-mozilla-cloudflare-google-vs-world/:
Welles. Het is te zien aan het "content type"-byte in het netwerkverkeer.
(tenzij deze byte zoals ook certificaten (zoals ik van E.v.S. vernam) bij TLS1.3 ook in de secure layer is opgenomen?)
Overigens Amazon is de partij met het spam-IP. Waarom geef je mozilla-cloudflare-google de schuld, en niet Amazon?

Oud nieuws. Ze hebben dit naderhand weer ingetrokken.

https://www.netsparker.com/blog/web-security/pros-cons-dns-over-https/
TOP artikel.

En dit niet alleen op DoH-gebied... "deze wereld is overgeleverd aan de onvolmaaktheid".
Daarom is er altijd wat te doen. ; )

@ anoniem van 15:40,

Dank voor je gewaardeerde reactie. Ben het eens met de algehele strekking, in het bijzonder waar je zegt, dat er in deze onvolmaakte wereld en zeker op de Internet infrastructuur, altijd wat te doen blijft en zal blijven. Een waarheid als een koe en m.i. onomstreden.

Waar we dan over moeten nadenken is de rol van Google, CloudFlare en secundair ook Mozilla bij het tot stand komen van nieuwe protocollen en het pushen van HTTPS Everywhere, dit genoemde DoH en waarom weer minder acceptatie voor
DNSSEC bijvoorbeeld. Ik kan me niet aan de indruk onttrekken en dat na ruim twaalf jaar 3rd party cold recon website security analyse en website foutenjagen, dat er zeker hierbij de core business behoefte van deze multinationale grote dataspelers meespeelt.

Ze maken deze keuze(n) bewust. Natuurlijk is er een algemene veiligheidscomponent, die onomstreden is. HTTPS Everywhere geeft een veiliger verbinding, maar men weet nooit wat voor brakke website er achter zo'n connectie kan schuilgaan.

Daar wordt de lat niet echt hoger gelegd. Daar wordt voorlopig niets aan minimale eisen afgedwongen.
Hoogstens wordt er geblacklist, als het de spuigaten uitloopt geblokkeerd of neergehaald,
als het algemeen belang niets anders meer toelaat.

Bij DoH helpt dit de veiligheid zeer beslist, bij scanresultaten van Virus Total (verworven door Google)
en via Google Safe Browsing alerts in de Google en Google-achtige browsers,
is men eveneens goed bezig. Het is niet alles commercieel en vanwege dit kommer en kwel.

Men wil dus vervolgens het liefst alles in de browser laten aflopen. Dat is een belangrijke observatie.

Echter worden er geen eisen gesteld bijvoorbeeld aan de vaak jammerlijk slechte beveiliging door verouderd CMS
(als Word Press, op PHP gebaseerd)bijvoorbeeld, verlaten code en af te serveren kwetsbare code bij JQuery bibliotheken).

Ook te weinig implementatie van best security policies (headers, sri, http-only cookies, miXedd content (dat wordt de volgende slag om dat vervolgens in de browser te gaan weren) e.d.

De browser wordt zodoende steeds veiliger. De websiteserachter helaas nog zeer onvoldoende.
Worden private websites in een later stadium daarom langzamerhand geweerd?
En zal er slechts ruimte overblijven voor websites van de grote jongens met een zekere basis-veiligheidstandaard?
De tijd zal het leren.

luntrus

Hee, pas op, ieder zijn taak he. Nog lang geen tijd om te gaan rentenieren. Wees blij dat je wat te doen houdt.... ; )

Voor zover ik kan nagaan is dit een beperkt content type veld dat slechts uit enkele content-type-waarden kan bestaan.
Ik verwacht niet dat de DoH content types erbij zullen komen, en dat het in TLSv1.3 waarin men heeft getracht unencrypted metadata te vermijden het waarschijnlijk is opgenomen in de encrypted layer, dus niet langer direct zichtbaar/controleerbaar.

Wat natuurlijk in dit geval nog wel een optie zou kunnen zijn, is simpel de standaard op dit punt aanpassen.
Men kan zich afvragen of het nu zo erg is dat een netwerkpakket zich aan de buitenkant laat kennen als zijnde DoH verkeer. Immers uit het IP-adres van de DoH-server dat open en bloot in het netwerverkeer staat is toch al wel af te leiden dat het om DoH-verkeer gaat.
Hoewel het mogelijk is om verkeer van/naar IP-adressen van DoH providers te filteren (firewall), moet men dan wel alle IP-adressen van alle DoH servers kennen.
Veel gemakkelijker is het als aan 1 specifieke byte in het netwerkverkeer reeds is te zien dat het om DoH-verkeer gaat,
zodat met een te ontwikkelen simpele tool die test op deze byte al het DoH verkeer kan worden tegengehouden in netwerken waar DoH niet wenselijk is. (al of niet tijdelijk)

Moet je wel over de decryptie keys beschikken, t.b.v. je SSL offloader. Wanneer het gaat om de eigen DNS server, waarbij je deze hebt, dan kan je ook simpelweg monitoren op de server i.p.v. op netwerk niveau.

Zie onder punt 3 in mijn eerdere reactie van 08-10-2019, 22:22 waarom velen dat onwenselijk vinden (https://security.nl/posting/625048#posting627037).

Beetje muggenziften, maar je hebt geen "decryptie keys" nodig. Er is gewoon sprake van twee geheel gescheiden verbindingen, elk met hun eigen versleuteling:
De MitM genereert, on the fly, een sleutelpaar + webservercertificaat als ware het van de echte server, en speelt daarmee voor certificaatuitgever. Dat webservercertificaat ondertekent de MitM met haar "root' private key (uit een ander sleutelpaar), passend bij een public key in het rootcertificaat van die MitM. Om certificaatfoutmeldingen op clients te voorkomen, moet op allen dat rootcertificaat als "trusted" zijn geïnstalleerd.

De vraag is of je zoiets wilt (zie de bijdrage waar ik eerder naar verwees): qua security creëer je hiermee een gevaarlijk single point of failure met een enorme geschiedenis aan blunders en kwetsbaarheden.

Helaas vrees ik dat DoH, maar ook TLS v1.3, steeds meer bedrijven richting zo'n device zullen dwingen. En de discussie met diegenen die, op landniveau, achterdeurtjes in encryptie willen, zal hierdoor nog verder verharden - met een onvoorspelbaar eindresultaat dat best wel eens de verkeerde kant op kan gaan (namelijk geen fatsoenlijke encryptie voor zich netjes gedragende mensen, zie ook https://www.security.nl/posting/468370/Encryptie+voor+leken+-+en+waarom+verzwakken+onverstandig%252C+en+verbieden+zinloos+is).

@Erik van Straten,

Dus mijn conclusie DoH betekent nog meer "security through obscurity" of misschien ook wel "less security through obscurity" kun je die onderschrijven?

De gaande ontwikkelingen wijzen in die richting en niet alleen op landelijk niveau, maar ook in de cybercriminele sfeer.

Iemand heeft eens gezegd "Op het moment, dat de gewone eindgebruiker geen deugdelijke encryptie meer bezit,
bezitten slechts overheden en criminelen over deugdelijke encryptie" (in dit geval voor internet connectie).

We zouden eigenlijk meer beveiligingseisen moeten krijgen, voor brakke servers, voor brakke websites en niet alleen voor Big Tech en de Rulers of Old uit de wind te kunnen houden. Je kunt het dus niet alleen maar overlaten aan Silicon Valley en Silicon Forest (Oregon), dat is na een paar decennia al wel vastgesteld, dat ze de luxe en het monopolie niet aankunnen zonder het te misbruiken voor eigen nepotisme en meer. "Als de vos de passie preekt, boer let op je kippen".

luntrus

Nee. Het gaat hier om grote commerciële bedrijven die handig inspelen op de kleine groep mensen die, post-Snowden, uit principe niet gevolgd willen worden, en een (vermoedelijk veel grotere) groep mensen die wel wat te verbergen hebben (vaak klein, soms groot) en denken anoniem het internet op te kunnen.

Echter, aan het gratis leveren van privacy en/of anonimiteit valt geen droog brood te verdienen, terwijl je er wel vijanden mee maakt (denk aan eigenaren van auteursrechtelijk beschermd materiaal en opsporingsdiensten die speuren naar illegale handel in wapens en verdovende middelen). Het kan niet anders dan dat hier een verdienmodel achter zit - en je die verwachte privacy en anonimiteit uiteindelijk niet gaat krijgen (wellicht worden het, na voldoende vendor lock-in, uiteindelijk betaalde diensten). Helaas zijn er nog steeds veel mensen die denken dat Air-Miles en WhatsApp gratis zijn...

Als -beoogd realistische- privacyvoorvechter denk ik dat we onze handen mogen dichtknijpen als inlichtingendiensten en hun ministerbazen genoegen blijven nemen met het relatief eenvoudig kunnen achterhalen wie met wie communiceert, maar niet zo eenvoudig wat we communiceren. Overigens kan het ook in je nadeel zijn als je met een nette website op het IP-adres van een shared-hosting server communiceert, en later blijkt dat op datzelfde IP-adres ook een kinderpornosite draaide (met DoH plus TLSv1.3 ziet niemand "onderweg" welke website op een IP-adres je bezoekt). Absolute anonimiteit vind ik overigens onwenselijk, want mensen die zich misdragen (ten koste van anderen) moet je uiteindelijk ter verantwoording kunnen roepen. We hebben niet voor niets kentekenplaten op onze auto's en brommers (waarom trekkers niet, is me een raadsel).

Laten we niet onze hand overspelen, zeker niet met DoH dat veel nieuwe risico's met zich meebrengt, in ruil voor een m.i. valse belofte van privacy en/of anonimiteit.

@ Erik van Straten,

Valide argumentatie en ik deel je nuchterheid bij de verwachting dat DoH een soort van panacee zou kunnen zijn.
Dat kan het namelijk niet. Niets op dit ondermaanse is een panacee of ooit gebleken.

Beveiligingsonderzoekers en de nationale cyber taskforce hebben al duidelijk een voorkeur uitgesproken voor DoT,
ten nadele van DoH.

Ik zie ook hier duidelijk de hand achter van de grote Big Tech Data Industrie,
die als ware monopolisten overal zo veel mogelijk de dienst willen gaan uitmaken.

De rol van jou en mij, als eindgebruiker/produkt wordt steeds onbetekender gemaakt.
Wij dienen alleen, voor het liefst zo ongelimiteerd mogelijk, de winstoptimalisatie.

De browser van vandaag is of Google Chrome of een kloon daarvan of heeft dechrome engines tenminste.
Google's proliferatie op zowat elk Interwebz terrein is ontzagwekkend en tevens angstwekkend in omvang.
In Nederland zo'n proliferatie van 93%.

Vooralsnog is er behalve de markt niets of niemand in staat deze globalistische reuzen,
zoals Google, facebook, Amazon en laatstelijk CloudFlare en Alibaba enigszins in te (kunnen) tomen.

Of men ziet de gevaren niet of men wil ze niet zien of zit in een positie, dat men ze niet kan zien
(gebrek aan technisch inzicht om security op de infrastructuur goed te kwalificeren in termen van veilig/onveilg(er).

Het ergste is het alternatie. Dit is onbetekenend en meer idealistisch van aard,
de non-propriety software evangelisten, die echter de propriety software gedreven kudde (Windows en Google-Android)
niet van hun ingewortelde gewoonten kunnen losweken.
Die grote kudde lijdt namelijk aan een veel te groot geworden afhankelijkheid.
Ik wil het woord verslaving niet laten vallen.

Ik ben een adept van een briljante resource hacker en searchlore guru, de veel te vroeg gestorven F.R.A.V.I.A.
De man was idealist en wars van elke vorm van smut en advertenties.

Een puristische verdediger van het Internet als vrij toegankelijke informatiebron.
Van hem de uitspraak, dat een goede zoeker gevaarlijker is dan een goede hacker.

Zo functioneert het Internet al lang niet meer en misschien heeft het wel nooit zo gefunctioneerd
Of is het nooit de bedoeling van Darpa en de Amerikaanse instanties geweest om zo te (laten) functioneren?

Het is ontsnapt en nu doet men gradueel en in kleine stapjes weer pogingen om de jjin weer terug in de fles te krijgen,
wat nog maar niet goed lukken wil, ondanks de verwoede pogingen van overheden en commercie.

Wij moeten steeds blijven zorgen, dat dat nog steeds maar niet lukken wil ;).

luntrus

Klopt helemaal van die panacee, luntrus,
we komen hier niet verder dan een pannekoek. (met sinds 1995 als alternatief: pannenkoek)

Alleen: een bedrijf als Google heeft DOH niet nodig om gebruikers nog meer te kunnen bespioneren,
omdat ze al talloze manieren hebben waarmee ze hetzelfde doen.