Chrome blokkeert third-party-cookies in incognito en rolt dns-over-https uit

Google gaat third-party-cookies voortaan automatisch blokkeren in de incognitomodus van Chrome. De browser krijgt een duidelijker privacybeheer, en ondersteunt standaard dns-over-https.

Google heeft het menu waarin de privacyinstellingen worden beheerd aangepast. Het nieuwe ontwerp is volgens het bedrijf overzichtelijker. Het wordt onder andere makkelijker om cookies te beheren en gebruikers kunnen ervoor kiezen om third-party-cookies in het algemeen te blokkeren. Ook toont Chrome duidelijker de sectie waarin staat welke websites permissie hebben tot bijvoorbeeld de camera of microfoon.

Alle third-party-cookies worden voortaan standaard geblokkeerd in de incognitomodus van Chrome. Gebruikers kunnen er vervolgens zelf voor kiezen dergelijke cookies toe te staan via een pictogram in de browser.

Google voegt ook een optionele Enhanced Safe Browsing toe. Dat is een opt-in-functie waarmee url's en downloads proactief worden gescand. Het standaard Safe Browsing doet dat ook al, maar dan tegen een lokale lijst die ieder half uur bijgewerkt wordt. Bij Enhanced Safe Browsing wordt de url in realtime gecheckt door een sample van een verdachte pagina naar Google te sturen. Als een gebruiker ingelogd is bij Chrome dan wordt die data tijdelijk gelinkt aan een Google-account. Op een later moment wordt dat weer geanonimiseerd.

Google begint de komende tijd ook met de uitrol van dns-over-https of DoH. Daarbij worden dns-queries versleuteld via ssl. Chrome kijkt dan eerst of de huidige dns-provider dns-over-https aanbiedt. In dat geval wordt DoH automatisch ingezet. Anders blijven de bestaande dns-instellingen actief.

Google zegt dat de nieuwe features 'in de komende weken' worden uitgerold voor gebruikers. Dat gebeurt aanvankelijk voor de desktop en de Android-versie van de app.

Reacties (69)

[Bor]

DNS over HTTPS (DoH) heeft niet alleen voordelen. De security wereld is hier verdeeld over. Interessant leesvoer; DNS-over-HTTPS causes more problems than it solves, experts say

[GertMenkel]

Het nadeel van DoH is dat het veilig is tegen afluisteren, precies waar het voor bedoeld is. Alle problemen zoals ze gesteld zijn in dit soort artikelen zijn ook reden om HTTPS stop te zetten.

De bedrijven en experts die hier vooral een probleem bij hebben zijn mensen die werken bij bedrijven waar DNS-data wordt gebruikt om het netwerk te monitoren. Als DoH een probleem vormt, was dit voorheen al een probleem; niets weerhoudt malware ervan om nu al contact te zoeken met diverse online DNS resolvers over allerlei protocollen.

Men wil monitoren zonder al het verkeer te monitoren, alsof dat mogelijk is. Of je zet een proxy op die TLS onfsleutelt, of je accepteert dat je data kunt lekken. De enige reden dat de oude methoden van netwerkintrospectie werken is omdat de malware die de mensen die dit roepen dagelijks tegenkomen niet geavanceerd genoeg is om iets anders dan DNS te gebruiken, en dat zal ook zo blijven nadat Chrome DoH inzet.

Men probeert DoH te ontkrachten door te roepen "ja maar SNI en OCSP zijn toch niet verlsleuteld" en kiezen er vervolgens maar voor te negeren dat encrypted SNI actief wordt getest door cloudflare en browsers en dat de meeste mensen (Chrome en Edgium-gebruikers) helemaal geen OCSP gebruiken. Zodra DoH gemeengoed is, zal SNI ook niet meer zomaar passief uit te lezen zijn vermoed ik.

Men begint ook nog wel eens over eigen blocklists en wat dan ook, maar het draaien van je eigen DoH-server is niet lastiger dan het draaien van je eigen DNS-server.

Ik ben zelf veel meer fan van DoT omdat ik het dom vind om alles maar over JSON te doen, maar de argumenten die hier meestal worden aangehaald zijn achterhaald voor het gros van de mensen. Het staat een bepaalde vorm van afluisteren niet meer toe, that's it. Dat sommige good guys zoals dure firewalls en de AIVD dat voor "goede dingen" doen betekent niet dat hier ook een hele hoop mee misgaat.

De meeste mensen die hard tegen DoH protesteren zijn Amerikaanse bedrijven die data vergaren, firewallproducenten die hun software niet willen updaten, systeembeheerders die hun netwerk niet willen aanpassen en een kleine groep mensen die protesteert tegen het instellen van dezelfde DNS-server bij alle mensen. Met die laatste groep ben ik het eens, de rest heeft zich maar aan te passen net zoals ze bij de opkomst van HTTPS moeten doen.

[Bor]

Het nadeel van DoH is dat het veilig is tegen afluisteren, precies waar het voor bedoeld is.

Heb je het artikel ook gelezen? Er worden veel meer problemen aangeduid:

• DoH doesn't actually prevent ISPs user tracking
• DoH creates havoc in the enterprise sector
• DoH weakens cyber-security
• DoH helps criminals
• DoH shouldn't be recommended to dissidents
• DoH centralizes DNS traffic at a few DoH resolvers

Dat lijken mij behoorlijk issues die je niet af kunt doen met de generalisaties onder aan jouw bericht. Je geeft ook aan dat de argumenten die worden aangehaald achterhaald zijn voor het gros van de mensen. Daar zou ik graag onderbouwing zien. Ik denk namelijk dat dit feitelijk helemaal niet klopt. Zaken als DNS filtering worden in zeer veel bedrijven gebruikt voor legitieme doeleinden. Kan malware er omheen? Jazeker. Echter DoH maakt het wellicht zelfs makkelijker voor malware om ongezien te blijven:

DoH will give new opportunities for bad actors to propagate malware, spam and botnets. Once they use DoH, as some botnets have already started doing for command-and-control traffic, their DNS traffic will be encrypted and anonymised, making it hard to deploy countermeasures to protect against and mitigate these serious security threats. This is likely to have an adverse impact on cybersecurity both at a network/country level as well as for end users. Use of DoH could make it slower to identify DNS-based DDoS attacks, more difficult to attribute patient-zero for malware infections and harder to block access to botnet command-and-control nodes. A proof of concept exfiltration channel tool based on DoH [GODOH] already exists and it is reasonable to expect others which are much less benign will emerge in the future.

Bron; https://tools.ietf.org/id/draft-reid-doh-operator-00.html

Kan je de doorsnede gebruiker beschermen tegen kwaadaardige domeinen etc? Ja, ook dat kan in beperkte mate.

Het bijzondere is ook dat het juist niet alleen de data vergarende bedrijven zijn die protesteren. Hier met data hoarder Google heb je daar het ultime voorbeeld van. Door slim in te springen levert DoH straks meer informatie dan de andere partijen hebben, mede omdat er maar een handjevol DoH resolvers zijn waarbij o.a. de browsers voorgebakken resolvers gebruiken.

De "DNS over HTTPS (DoH) Considerations for Operator Networks " draft haalt nog meer issues aan, waaronder;

5.4. Managed network services

The provision of managed network services, for instance to corporate or other enterprise clients will be affected by DoH. It could negatively affect bring-your-own-device policies which might introduce devices into these networks that are configured to use third party DoH servers. For instance there is a risk that internal domain names used extensively in such networks could leak to external DoH servers, presenting obvious privacy and security issues.

Bron: https://tools.ietf.org/id/draft-reid-doh-operator-00.html

Een ander nadeel is dat DoH in de applicatie wordt geïmplementeerd in tegenstelling tot de kernel of een os library waardoor het gedrag per applicatie kan verschillen. Tevens maakt dit het beheer intensiever en lastiger.

[Reactie gewijzigd door Bor op 24 juli 2024 16:40]

[GertMenkel]

• DoH doesn't actually prevent ISPs user tracking: dit valt in de categorie "een wet tegen moord voorkomt niet alle moord dus is nutteloos". Het voorkomt wel daadwerkelijk veel gevallen van tracking, aangezien providers hun systemen moeten ombouwen om andere tracking uit te voeren (die binnenkort ook niet meer beschikbaar zijn)
• DoH creates havoc in the enterprise sector: alleen bij bedrijven waar dit voorheen ook al kon, niks nieuws dus behalve dat bedrijven nu hun lekken moeten dichten.
• DoH weakens cyber-security: DoH versterkt zowel de C als de I van het bekende CIA-trio van cybersecurity. Hier zit niks achter voor zover ik kon lezen behalve een vaag gevoel. Afluisteren van apparatuur die niet onder jouw beheer valt wordt moeilijker, dat is alleen maar een goed iets in mijn ogen. Joop de IT-er die zeven jaar gelden een keer een of andere vage securitydoos gekocht heeft zal roepen dat alles onveiliger wordt want nou werkt de doos niet meer, maar de doos was al jaren niet meer in staat voldoende beveiliging te bieden.
• DoH helps criminals: ditzelfde argument is gebruikt tegen let's encrypt, HTTPS en als argument voor de sleepwet. Ja, als iedereen meer privacy heeft, hebben criminelen dat ook. Exfiltratie en alternatieve DNS-systemen via verborgen verkeer bestaan al jaren, evenals een encryptielaag daar overheen.
• DoH shouldn't be recommended to dissidents: de beweging om DoH in plaats van een volledige VPN te gebruiken is dom. Ik ken zelf niemand die beweert dat DoH je beschermt tegen het lokale regime en dit argument voelt als een stroman.
• DoH centralizes DNS traffic at a few DoH resolvers: dit is waar van de standaardconfiguratie, maar hetzelfde kun je ook zeggen over de AT&T, Comcast, Ziggo, KPN-DNS-servers. Hier is een makkelijke oplossing voor, namelijk meer publieke DoH-servers. Dit is overigens irrelevant voor dit artikel, omdat Chrome dus de DoH-server van de ISP gebruikt en niet die van een willekeurige derde partij. Aangezien veel Amerikaanse providers en websites geen DNSSEC doen, zorgt dit dus ondanks het gebrek aan beveiliging tegen meekijken alsnog voor verbeterde integriteit van DNS +-requests puur door man-in-the-middle attacks moeilijker te maken.

DNS-filtering in bedrijven wordt zeker gedaan, maar bedrijven hebben ook group policies om DoH uit te zetten. Bij Firefox kunnen ze een NXDOMAIN op het canarydomein teruggeven en DoH staat uit. Bij Chrome gebruikt de browser de interne server van het bedrijf dus blijft filtering bestaan. Bedrijven moeten dan niet vergeten om dingen als de data saving proxy in Chrome uit te zetten, anders zijn medewerkers er alsnog zo omheen natuurlijk.

Goed, voor de onderbouwing: gebruikers kunnen om firewalls en filters heen door een VPN op poort 443 over TLS te pakken. Oplossing daartegen: HTTPS-introspectie of accepteren dat je medewerkers je firewall kunne omzeilen met een populaire app van een USB-stick. Het voordeel van HTTPS-introspectie: je kunt op dat moment DoH al onderscheppen en monitoren. Probleem opgelost.
Kan je bedrijf geen TLS-interspectie maar beheert het wel alle endpoints? Populaire DoH-servers blokkeren in de firewall en DoH uitzetten met group policy.
Heeft het bedrijf geen toegang tot HTTPS-introspectie of group policy? Dan kan iedereen dus met een VPN om de beveiliging heen.

Antivirussoftware zit tegenwoordig dieper in het OS en controleert niet alleen de DNS-naam maar ook IP-adressen en verifieert die met de cloud. DNS zonder DNSSEC is niet te vertrouwen dus dat doen goede producten ook niet.

Voor consumenten biedt dit wel een uitkomst, omdat providers in Amerika (maar ziggo heeft het ook gedaan) voor ieder niet-bestaand domein het domein voor je resolven naar een zoekpagina die de URL en je IP verzamelt en doorverkoopt. Voor dat soort ISP's vind ik dat de data aan cloudflare en niemand anders geven minder schade toebrengt dan de data sowieso aan verkopers door te geven. Dit ook omdat de helft van het internet onderhand achter cloudflare hangt en je verzoek dus hoe dan ook wel bij hun terecht komt.

Voordeel voor veel consumenten, geen nadeel voor bedrijven die hun zaken op orde hebben, een wakeup call voor bedrijven die hun zaken niet op orde hebben.

Zoals ik zei zijn al deze argumenten ook gebruikt tegen de algemene invoering van HTTPS. Het zou certificaatboeren te veel macht geven, het zou bedrijfsnetwerken gevaarlijker maken, het zou criminelen in de hand spelen, tracking niet stoppen, mensen een false sense of security geven en het zou inlichtingendiensten het leven zuur maken tegen kinderpornoterroristen of wat het argument op dat moment ook was. Nu is het merendeel van het web versleuteld, zijn je gegevens op de draad veiliger dan ooit en kun je veilig verbinden met de openbare WiFi van de Starbucks door dingen als HSTS en secure cookies, zolang je je Windows updates maar installeert. De wereld is niet vergaan en de PC's van 's vaderlands bedrijfsnetwerk zitten niet spontaan vol met Russische cryptolockers.

Google biedt een DoH-server aan maar stelt deze dus niet als default in. Het ontvangt ook al ontiegelijk veel DNS requests en doet daar niks mee omdat het een EU-boete van jewelste zou zijn. In Californië zou het een class-action lawsuit kunnen veroorzaken die ze miljarden kost. Ik verwacht dezelfde raadzaamheid bij Cloudflare en ieder ander bedrijf dat in de EU opereert en groot genoeg is om als monopolist aangemerkt te worden door de Europese Unie. En laten we eerlijk zijn, Facebook zit op iedere pagina en in iedere app (zie de golf van crashes van ongerelateerde apps op iOS laatst toen Facebook een serverprobleem had), Google tag manager en Google ads zitten in alle telefoons, tv's, magnetrons en smart watches, Microsoft uploadt willekeurige office-documenten naar hun toe als je Word crasht en de hele wereld heeft 24/7 ergens een Cloudflare-website openstaan. Denk je echt dat DoH daar nog een significante impact op heeft? Ik draai zelf natuurlijk een eigen DNS server met DoT en DoH maar voor de gemiddelde gebruiker is de startpagina niet meer op Google of msn.com zetten al iets raars. Iedereen draait SafeSearch, Google DNS-voorspelling en alle andere Chrome/Edge features met standaardinstellingen.

Ik zou het knap vinden als DNS-filtering überhaupt een effect heeft boven de domeinfiltering die browsers doen door middel van Google's safe browsing die overal aan staat. 't is een leuke feature voor adblocking met pihole, maar daar heb je het nut van DNS-filtering er ook wel uit. Een kind van 14 is al prima in staat om een browser te downloaden met een VPN om daarmee naaktfoto's op te zoeken (heb gewerkt bij een bedrijf dat zich daarin specialiseerde en daar heb ik wel geleerd dat de enige beveiliging volledig apparaatbeheer is) en een kind dat jonger is kent wel een vriendje of een vriendinnetje met die baardigheden
In dat opzicht zou ik me zelf meer focussen op dingen als Elsagate als ouder.

[Bor]

DoH doesn't actually prevent ISPs user tracking: dit valt in de categorie "een wet tegen moord voorkomt niet alle moord dus is nutteloos". Het voorkomt wel daadwerkelijk veel gevallen van tracking, aangezien providers hun systemen moeten ombouwen om andere tracking uit te voeren (die binnenkort ook niet meer beschikbaar zijn)

Niet alleen gaat je vergelijking niet op; kijk eens wie er allemaal op de DoH trein stappen; juist bedrijven als Google etc die baat hebben bij het kunnen tracken van gebruikers; sterker nog; het is min of meer de manier hoe Google geld verdiend.

DNS-filtering in bedrijven wordt zeker gedaan, maar bedrijven hebben ook group policies om DoH uit te zetten.

Leuk dat je dit aangeeft gezien DoH niet in het OS maar in de applicaties wordt geïmplementeerd. Dat betekent dus per applicatie een GPO setting maar wacht, die zijn vaak helemaal niet voorhanden. Per applicatie wisselen de mogelijkheden om DoH uit te zetten en in lang niet alle gevallen is dat blijvend mogelijk.

DoH creates havoc in the enterprise sector: alleen bij bedrijven waar dit voorheen ook al kon, niks nieuws dus behalve dat bedrijven nu hun lekken moeten dichten.

Je gaat makkelijk voorbij aan het feit dat de maatregelen die bedrijven hebben geïmplementeerd niet onfeilbaar zijn maar wel degelijk behoorlijk effectief.

Kan je bedrijf geen TLS-interspectie maar beheert het wel alle endpoints? Populaire DoH-servers blokkeren in de firewall en DoH uitzetten met group policy.

Met deze aanpak mis je de niet populaire DoH servers. Wat betreft group policy instellingen; zie hier boven.

Voor consumenten biedt dit wel een uitkomst, omdat providers in Amerika (maar ziggo heeft het ook gedaan) voor ieder niet-bestaand domein het domein voor je resolven naar een zoekpagina die de URL en je IP verzamelt en doorverkoopt. Voor dat soort ISP's vind ik dat de data aan cloudflare en niemand anders geven minder schade toebrengt dan de data sowieso aan verkopers door te geven. Dit ook omdat de helft van het internet onderhand achter cloudflare hangt en je verzoek dus hoe dan ook wel bij hun terecht komt.

Een soortgelijk issue heb je met de DoH providers. Wederom; kijk wie dit o.a. aanbieden en naar het business model. Doh != cloudflare, dat is slechts 1 van de aanbieders.

Ik zou het knap vinden als DNS-filtering überhaupt een effect heeft boven de domeinfiltering die browsers doen door middel van Google's safe browsing die overal aan staat. '

Heb je bijvoorbeeld een ForcePoint (voorheen Websense) wel eens getest? Dan zie je gelijk dat je veel meer mogelijkheden en effectiviteit behaald dan alleen safe browsing of safe search.

Ik lees veel "ja maar.. in situatie x" en drogredenen. Wanneer we iets nieuws op grote schaal gaan doen moet het gewoon kloppen / beter zijn dan de huidige situatie. Dat is DoH helaas niet op alle fronten.

[Reactie gewijzigd door Bor op 24 juli 2024 16:40]

[GertMenkel]

Niet alleen gaat je vergelijking niet op; kijk eens wie er allemaal op de DoH trein stappen; juist bedrijven als Google etc die baat hebben bij het kunnen tracken van gebruikers; sterker nog; het is min of meer de manier hoe Google geld verdiend.

Als ik zo kijk zie ik vooral bestaande DNS-servers, netwerkbeheerders, hosting providers en netwerkbackbones in de lijst staan. Die van Google wordt eigenlijk nog amper gebruikt volgens mij, vooral die van Cloudflare is momenteel populair omdat die in Firefox standaard wordt ingeschakeld. Cloudflare heeft weinig aan die informatie omdat hun hoofdservice DDoS- en trafficflowbeheer voor gebruikers is, niet het analyseren van gebruikers.

Leuk dat je dit aangeeft gezien DoH niet in het OS maar in de applicaties wordt geïmplementeerd. Dat betekent dus per applicatie een GPO setting maar wacht, die zijn vaak helemaal niet voorhanden. Per applicatie wisselen de mogelijkheden om DoH uit te zetten en in lang niet alle gevallen is dat blijvend mogelijk.

Waarom zouden applicaties nog zelf DoH implementeren als het OS het al voor ze doet? Browsers implementeren het omdat de OS-laag het nog niet heeft, maar ik verwacht niet dat MS Office of Photoshop zo hun eigen DoH client gaan implementeren. Te veel moeite en onderhoud voor nul winst.

Je gaat makkelijk voorbij aan het feit dat de maatregelen die bedrijven hebben geïmplementeerd niet onfeilbaar zijn maar wel degelijk behoorlijk effectief.

Malware en spyware die nu nog geen DoH doet, gaat dit ook niet straks ineens doen. De software en API is nu al enkele jaren beschikbaar dus als kwaadwillenden hier gebruik van zouden willen maken, hadden ze dat onderhand al wel gedaan. Malware-schrijvers gebruiken nog steeds IRC-kanalen voor communicatie met C&C-servers dus op protocolniveau zal het ze allemaal wel niet zoveel schelen.

Met deze aanpak mis je de niet populaire DoH servers. Wat betreft group policy instellingen; zie hier boven.

Dat klopt, maar met die aanpak pak je wel de voor de hand liggende servers waar normale, niet-per-se-kwaadaardige medewerkers van een bedrijf waarschijnlijk gebruik van zullen maken. Als je buiten de standaardlijstjes gaat werken, zit je tegen zo'n niveau van technische competentie te werken dat je DNS-filter sowieso nutteloos is. Ik denk zelf dat mensen sneller een VPN-extensie in hun browser installeren dan dat ze een self-hosted DoH-server gaan instellen op hun computer. Als het aankomt op puur DNS heb je dnscrypt, SOCKS-proxies, simpele TLS-tunnels, HTTP(S)-proxies, Tor bridges, etc. om je fancy DNS-filters te omzeilen.

Als de applicatie niet goed te beheren valt via GPO, wat doet die dan op een bedrijfslaptop? Waarom houdt de Windows firewall dat soort verkeer niet tegen?

[Wim-Bart]

Het verschil met DoH en niet DoH is heel erg simpel.

Met DoH loopt al het verkeer voor DNS requests via een grote aanbieder. Deze aanbieder ziet gewoon welke naam resolved wordt, want voordat het pakket gemaakt wordt met IP nummer wordt het ergens ingepakt. Daarnaast kan je ISP gewoon zien wel adres je naar toe gaat, mits je natuurlijk via een VPN gaat. Dus met VPN ziet je VPN provider het.

Zonder DoH ziet alleen je provider het wanneer je geen eigen DNS gebruikt.

Kortom, met DoH hebben veel meer partijen inzicht in je browser gedrag dan zonder DoH. Daarnaast is het niet mogelijk om controle te houden over welk onderdeel wat doet en zet je een hoop security buiten spel.

DoH zou wettelijk verboden moeten worden!

[GertMenkel]

Met DoH loopt al het verkeer voor DNS requests via een grote aanbieder. Deze aanbieder ziet gewoon welke naam resolved wordt, want voordat het pakket gemaakt wordt met IP nummer wordt het ergens ingepakt.

Ja niet dus:

Google begint de komende tijd ook met de uitrol van dns-over-https of DoH. Daarbij worden dns-queries versleuteld via ssl. Chrome kijkt dan eerst of de huidige dns-provider dns-over-https aanbiedt. In dat geval wordt DoH automatisch ingezet. Anders blijven de bestaande dns-instellingen actief.

Zonder DoH ziet alleen je provider het wanneer je geen eigen DNS gebruikt.

SIDN, de beheerder van .nl, heeft een databasesysteem dat alle top-level DNS requests opvangt en onderzoekt naar o.a. fraude. Door DNS-extensies wordt door recursieve DNS-servers ook een bron-range opgegeven (denk /24). Al die informatie staat ergens in een database opgeslagen. Let's Encrypt kan door middel van OCSP de helft van de websites die Firefox-gebruikers veroorzaken op het web theoretisch traceren.
Verisign zal dat ook voor .com hebben en .google zal al helemaal kapot worden gedatamined. Amazon, Microsoft, Google, GoDaddy, Ghandi, Leaseweb, TransIP etc. hebben ook grote DNS-resolvers die meer dan genoeg data van willekeurige internetters opvangen. Cloudflare heeft hun firewall voor meer dan 10% van het internetverkeer staan, en zij doen o.a. ook TLS termination, DNS en DDoS-verkeersanalyse.

Dan neem ik nog aan dat je niet je browsergeschiedenis automatisch synchroniseert in Chrome zoals veel mensen doen, dat je de DNS-predictieservice uitzet, je nooit op AMP-links klikt, je Facebook op DNS- en IP-level blokkeert om te voorkomen dat ze traceren welke knop je wanneer op je telefoon indrukt en dat je ISP geen SNI-monitoring doet (laat staan HTTP-scriptinjectie zoals in Amerika gebeurt). Oh, en image-caching proxies zoals Simpel ooit op hun netwerk gebruikte (die HTTP-requests naar afbeeldingen voor je doet, deze comprimeert, en dan met minder data naar je telefoon sturen) laat ik ook maar buiten beschouwing.

Aannemen dat alleen je ISP je DNS-request kan zien was misschien 20 jaar geleden waar. Tegenwoordig is het web een stuk complexer en is je DNS niet meer een privézaak tussen jou en je provider. De metadata van al het verkeer komt bij de grote DoH-bedrijven terecht zelfs al zou je heel het DNS-systeem in een lokaal hosts-bestand opslaan.

DoH zou wettelijk verboden moeten worden!

Wauw.

[Wim-Bart]

[...]
Ja niet dus:
[...]
Ah dus het antwoord op een DoH DNS naam resolve wordt magisch gevuld

DoH werkt heel eenvoudig.
1. Client doet aanvraag, deze aanvraag wordt in een HTTPS request ingepakt en naar der DoH server verzonden.
2. De DoH server pakt het pakketje uit, ziet daar in de vraag "geef mij ip adres van .www.tieten.nl", stuurt deze aanvraag door naar de root servers, die bij .nl uitkomen.
3. De .nl servers antwoorden met het IP adres.
4. Het IP adres wordt ingepakt in een HTTPS-response.
5. Client applicatie pakt het uit.

De DoH provider weet nu twee dingen. Het IP adres van de zaanvraag van www.tieten.nl en dat ie www.tieten.nl heet opgevraagd. Dit valt vrij eenvoudig te loggen. Stel, de DoH aanbieder is Cloudflare, toevallig die proxying en dergelijke doet voor o.a. Facebook, Google, Microsoftr, you name it en die ziet ook requests naar https://www.facebook.com gaan (via SNI data in HTTPS request) en ze kunnen een mooi profiel maken.

[GertMenkel]

Ik snap hoe DoH werkt en de gevaren die erbij horen. Ik vind echter dat de voordelen die je krijgt bij versleutelde DNS-verzoeken het de nadelen waard.

Nu kunnen niet Verisign en SIDN maar Cloudflare en Google je DNS-verzoeken analyseren. Verisign vertrouw ik persoonlijk sowieso niet en alhoewel SIDN mij prima lijkt, is een bedrijf met zo weinig mankracht toch minder goed in staat dit soort gegevens te beveiligen dan een multinational die DNS als bijzaak doet. Voor Cloudflare is DoH puur gewoon praktisch want dan zijn hun edge servers sneller.

Als ze toch al de TLS-termination en/of proxydienst regelen voor een website heeft een DNS-verzoek weinig toegevoegde waarde behalve misschien metrics om te zien of hun netwerk goed loopt.

DoH blijft een optie en tot de Nederlandse ISP's het aanzetten op hun servers zul je er in Chrome in ieder geval niks van merken.

Oh, en dat profiel maken kan Cloudlfare dus al, ook als je je eigen recursive DNS doet. Azure, AWS en Google Cloud kunnen het ook. De termination wordt vaak door clouddiensten gedaan omdat DDoS tegenwoordig zo makkelijk voor elkaar te krijgen, maar ook omdat alles tegenwoordig agile en in cloud clusters moet. Veel makkelijke hostingprovider zien voor websites niet alleen het domein in de SNI staan, maar ook het pad, de cookies, je wachtwoord en je authenticatietoken. Het internet is gecentraliseerd naar grote partijen als deze omdat het goedkoop veilig te maken is tegen aanvallen. Als je je eigen VPS of dedicated servers ergens ophangt zal je hosting provider je namelijk gewoon afsluiten zodra de DDoS die een twaalfjarige Rus op je server aan het uitvoeren te duur wordt voor hun "gratis" DDoS-beschermingsplatform. Zonder Azure/AWS/GCloud/GShield heb je namelijk nooit die bescherming.

Vergeet ook niet dat dit een risico is. Als Cloudflare gegevens blijkt te verzamelen van het vinkje dat in Firefox DoH aanzet, kan dat een Europese GDPR-boete opleveren van enkele miljoenen. 4% van de wereldwijde omzet is niet niks, en advocaten binnen dit soort bedrijven weten dat. Google wordt ieder half jaar ongeveer beboet door steeds hogere boetes dus ze zullen wel twee keer nadenken eer ze een trackingsysteem toevoegen aan hun DNS-service.

Ik denk dat mijn DNS-gegevens bij Cloudflare veiliger liggen dan bij Surfnet (mijn huidige internetaanbieder) of KPN/Ziggo. Ziggo heeft bij mij ooit een vage streek geleverd waar ze alle niet-resolvende domeinen doorstuurden naar een of andere datahandelaar die zich als een "makkelijke dienst" voor "verkeerdgetypte websites" voordeed. Dit was jaren terug, maar sindsdien weiger ik de Ziggo-DNS-servers als default in te stellen. Dan maar Google, daar weet ik tenminste wat ik kan verwachten.

Je mag het ermee oneens zijn en de instelling uitzetten in Firefox en eventueel Windows wanneer die komt, maar de trackingmogelijkheden bij DoH zijn in principe niet anders dan die van DNS zelf zolang je dezelfde DNS-server gebruikt, zoals heeft aangekondigd te gaan doen. Het is een kwestie van tijd tot je eigen ISP ook een server heeft en je op je oude gangetje door kan gaan. Ik prefereer zelf DoT (normaal DNS over TLS in plaats van JSON over HTTPS), wat overigens ook in Android is ingebouwd, maar beide zijn werkende standaarden die door de industrie worden geïmplementeerd.

Als laatste wil ik toevoegen dat een wijziging op DNS-gebied nodig is. De onzinnig-makkelijk te spoofen kwetsbaarheden van DNS zijn inmiddels met DNSSEC opgelost (in ieder geval voor Nederland, bij andere landen loopt het minder hard) maar DNS-servers zijn nog steeds een van de grootste DDoS-veroorzakers van het internet. Zodra we ongeauthenticeerde UDP-services hebben vervangen door services die eerst een goede handshake uitvoeren of door TCP, zal het internet een stuk veiliger en stabieler worden. De mate van amplificatie die DNS toestaat bij een DDoS is gewoon niet grappig meer en heeft downtime veroorzaakt bij belangrijke diensten en bedrijven. Nieuwe protocollen of wijzigingen van de oude structuur zijn nu eenmaal nodig.

[Wim-Bart]

De laatste die ik mijn privacy toevertrouw is wel Google. Google leeft van de kennis die ze over je hebben.

[Aetje]

Mh, als ik dat artikel zo lees, vraag ik me af of de problemen die genoemd worden echt problemen zijn:

"DoH doesn't block user tracking": Is het ook niet voor bedoeld. Het voorkomt echter wel dat ISPs (en andere kwaadwillenden) DNS responses aan kunnen passen, wat met unencrypted DNS verkeer niet echt moeilijk is, en maakt het lastiger voor ISPs om het gebruik van de eigen DNS te forceren.

"DoH bypasses enterprise policy": Als je dergelijke strikte regels wil toepassen doe je dat of via een proxyserver (en dan gaat DoH zelf ook niet meer lukken tenzij je de servers whitelist) of via firewalling, liefst nog clientside en per policy afgedwongen. En als je dergelijke strikte regels wil toepassen - hoe komen users dan bij de DNS configuratie? Configureer je de browser niet per policy? En als de users proberen om ongeauthoriseerde apps te draaien, dat geheel blokkeren?

"DoH weakens cybersecurity": Lijkt me frappant dat je DNS queries moet kunnen inzien en blokkeren om PCs veilig te houden. DNS zelf gebruik je om domein informatie te vinden, niet als communicatiemiddel - en als je het wel als communicatiemiddel gebruikt (bv command en control signaal voor malware), waarom dan niet direct een HTTPS verbinding naar een specifiek IP? Voor DoH moet je immers het IP van de DNS server weten.
DNS redirection is een mes dat aan twee kanten snijd: Aan de ene kant kan je het gebruiken voor beveiliging, aan de andere kant kun je het gebruiken voor censuur of juist voor aanvallen door gebruikers om te leiden naar een server waar ze niet heen willen. Mijn mening is dat DNS bedoeld is om de server die bij een specifiek adres hoort, te vinden. Wanneer je dat doel beter kan garanderen, heb je een beter DNS protocol. Niet voor mensen die graag je queries in willen zien en kunnen manipuleren, maar daar is DNS niet voor bedoeld!

[Wim-Bart]

Mh, als ik dat artikel zo lees, vraag ik me af of de problemen die genoemd worden echt problemen zijn:

"DoH doesn't block user tracking": Is het ook niet voor bedoeld. Het voorkomt echter wel dat ISPs (en andere kwaadwillenden) DNS responses aan kunnen passen, wat met unencrypted DNS verkeer niet echt moeilijk is, en maakt het lastiger voor ISPs om het gebruik van de eigen DNS te forceren.

Aanpassen is het minst erge, dat kan je oplossen met DoT (DNDS over TLS). DoH zet eigenlijk iedere andere infgratructurele oplossing buiten spel en dwingt je gebruik te maken van partijen zoals Google, Facebook, Cloudflare welke je gewoon kunnen tracken. Sterker nog, het enge an DoH is dat een apje op je telefoon een eigen DNS server kan gebruiken, waar misschien malafide injectie plaats vinden. DoH zet de deur open naar DNS injectie zonder dat dit te monitoren is.

"DoH bypasses enterprise policy": Als je dergelijke strikte regels wil toepassen doe je dat of via een proxyserver (en dan gaat DoH zelf ook niet meer lukken tenzij je de servers whitelist) of via firewalling, liefst nog clientside en per policy afgedwongen. En als je dergelijke strikte regels wil toepassen - hoe komen users dan bij de DNS configuratie? Configureer je de browser niet per policy? En als de users proberen om ongeauthoriseerde apps te draaien, dat geheel blokkeren?

DoH zorgt er voor dat er geen controle meer is op naam resolutie. Wanneer een applicatie DoH implementeert en deze werkt niet wanneer bijvoorbeeld https naar een DoH server uit staat, dan moet dit dus worden toegestaan, hierdoor moet je dus verkeer open zetten wat je misschien niet wil. Omdat je geen inzicht hebt in de opgevraagde DNS request zet je de deur open voor applicaties welke fout willen. Dit kunnen ook legitieme applicaties zijn die geinfecteerd zijn en in plaats van 1.1.1.1 bijvoorbeeld een command en control server van een botnet benaderen. Als beheerder zie je dat niet en AV software ziet dat ook niet.

"DoH weakens cybersecurity": Lijkt me frappant dat je DNS queries moet kunnen inzien en blokkeren om PCs veilig te houden. DNS zelf gebruik je om domein informatie te vinden, niet als communicatiemiddel - en als je het wel als communicatiemiddel gebruikt (bv command en control signaal voor malware), waarom dan niet direct een HTTPS verbinding naar een specifiek IP? Voor DoH moet je immers het IP van de DNS server weten.
DNS redirection is een mes dat aan twee kanten snijd: Aan de ene kant kan je het gebruiken voor beveiliging, aan de andere kant kun je het gebruiken voor censuur of juist voor aanvallen door gebruikers om te leiden naar een server waar ze niet heen willen. Mijn mening is dat DNS bedoeld is om de server die bij een specifiek adres hoort, te vinden. Wanneer je dat doel beter kan garanderen, heb je een beter DNS protocol. Niet voor mensen die graag je queries in willen zien en kunnen manipuleren, maar daar is DNS niet voor bedoeld!

Meeste botnets en dergelijke zitten niet op een vast IP, zijn heel dynamisch. Het probleem met DoH is dat het ieder IP adres in de wereld kan zijn, en je komt er nooit achter wat die adressen zijn. Daarom blokkeren op IP als beveiliging werkt niet. Op het moment zijn er al zoveel server die DoH aanbieden, welke je niet kan blokkeren omdat andere zaken niet meer werken. DoH maakt eigenlijk een ontraceerbare tunnel naar iets wat je niet kent. Je zet eigenlijk gewoon de deur open naar iets onbekends zonder dat je weet wie of wat er via die deur naar binnen komt. Een ander probleem is, dat je binnen een bedrijf ook niet meer met blacklist kan werken vcoor security, of thuis met een blacklist kan werken. Fijne gedachte dat DoH eigenlijk kinderen vrije toegang geeft tot alle porno en geweld in de werkeld zonder dat je diet ziet of in de gaten hebt.

[djwice]

SNI: Server Name Indication
Laat inderdaad ook weten welke domeinen je bezoekt.
En de meeste websites delen IP-adressen met een andere website, waardoor ze SNI nodig hebben om zonder decryptie van de content goed te worden gerouteerd.

Maar stel dat we over een tijdje allemaal IPv6 gebruiken voor de meeste websites, dan hoeven die sites geen SNI te gebruiken, dan wordt er gerouteerd op IP... alleen dat unieke nummer, zit ook in de pakketjes, immers anders komen ze niet bij de juiste server aan...

Dus zolang het meeste van jouw verkeer langs 1 punt gaat kan dat punt monitoren waar je naar toe gaat.
En met een beetje meer info (grootte van de request / response + request order) kan van publieke content geraden worden om welke content het gaat.

[Reactie gewijzigd door djwice op 24 juli 2024 16:40]

[GertMenkel]

SNI: Server Name Indication
Laat inderdaad ook weten welke domeinen je bezoekt.
En de meeste websites delen IP-adressen met een andere website, waardoor ze SNI nodig hebben om zonder decryptie van de content goed te worden gerouteerd.

eSNI: https://tools.ietf.org/html/draft-ietf-tls-esni-06, actief in ontwikkeling en in te schakelen in moderne browsers via flags. Wordt ondersteund door Cloudflare, dus dat is al meer dan 10% van het wereldwijde web dat niet te passief uit te lezen valt.

Maar stel dat we over een tijdje allemaal IPv6 gebruiken voor de meeste websites, dan hoeven die sites geen SNI te gebruiken, dan wordt er gerouteerd op IP... alleen dat unieke nummer, zit ook in de pakketjes, immers anders komen ze niet bij de juiste server aan...

Dus zolang het meeste van jouw verkeer langs 1 punt gaat kan dat punt monitoren waar je naar toe gaat.
En met een beetje meer info (grootte van de request / response + request order) kan van publieke content geraden worden om welke content het gaat

Dit klopt tot op een zekere hoogte (gebrek aan padding in TLS blijft een ding) maar de halve wereld hangt achter Apple, Amazon, Azure, Facebook caches, Google AMP, Cloudflare en Akamai. Grote bedrijven kunnen je al volgen en het zou ze veel te veel geld kosten om dit passief te doen, nog los van de wettelijke verantwoordelijkheid die zo'n systeem bij ze neer zou leggen (dank u, GDPR). Ook is het terugmappen van IPv6-adres naar server nog wel eens lastig aangezien virtual hosts ook gewoon bij IPv6 bestaan en je eigen IPv6-adres rouleert door middel van de privacy extensions.

SNI zal blijven want het is verdomd handig en niet-TLS-1.3-handshakes worden door middleboxes zoals bedrijfsfirewalls compleet gedropt (daarom ziet TLS 1.3 er op de draad uit als een TLS 1.2 session resumption). Met padding op TLS 1.3, gedeelde IP's zoals het nu ook is en eSNI wordt het toch best lastig om van een willekeurige stroom pakketjes te achterhalen welke pagina er wordt bezocht. Je zult actief moeten gaan onderzoeken voor iedere stream welke server erachter schuilt en een overzicht van alle domeinen + IP's moeten opbouwen om daar achter te komen. Nu alles in de cloud zit, kan de IP-toewijziging ook gewoon na een kwartier veranderen. SNI (en OCSP in Firefox) is het laatste struikelblok om dit spul onpraktisch genoeg te traceren te maken dat ISP's het niet kunnen doen.

[djwice]

Als je op AWS host is het zelfs heel makkelijk om de bezoekers data actief door amazon te laten analyseren, je kunt cloudwatch logs een prefix tag geven die er voor zorgd dat je toestemming geeft aan Amazon om die logs voor andere doeleinden te gebruiken, en dat wordt actief gedaan.

CloudWatch is de tool binnen AWS waar je al je logs van al je compute laat samen komen.

Voor Google wordt actief data aan elkaar gebonden op basis van data uit o.a. Google Now, deze staat op veel telefoons gewoon op de achtergrond aan. Het gebeurd regelmatig dat als ik over een onderwerp met iemand praat de zoekmachine al met 1 letter de juiste zoekzin suggereerd. Ook als iemand bij mij in de buurt bepaalde onderwerpen heeft gezogd zie ik dat de kans dat ik die onderwerpen gesuggereerd of geadverteerd krijg enorm toenemen. Door die segmentatie is de capaciteit die nodig is om dit te doen aanzienlijk kleiner dan je wellicht verwacht.

Denk bijvoorbeeld aan sterk gepartitioneerde external tables in een hyve, in slechts enkele honderden nano seconden de juiste data boven water. Er zijn diverse volwassen open source tools die deze techniek toepassen. Het algoritme dat in een Google Search Appliance zat maakte hier ook gebruik van, plus nog een in memory cache voor de laatst benaderde partities/pointers (waardoor opvolgende zoekopdrachten in dezelfde "hoek" steeds sneller werden). Ook op AWS worden vergelijkebare optimalisaties toegepast in diverse services.

Maar goed, dat heel andere koek. Je uitleg m.b.t. tot IP veranderen in cloud is inderdaad aan de orde, bijvoorbeeld als een edge locatie overbelast is, zie je dat de route heel snel wordt verlegd naar een andere edge locatie, eigenlijk zonder dat de eindgebruiker dat merkt (anders dan iets langzamer, maar vaak ook niet echt merkbaar bij normaal gebruik).
Ik zal me eens in die padding verdiepen, lang geleden gedaan, toen dacht ik dat ik het wel had gekraakt, maar dat zal vast weer zijn gewijzigd en verbeterd inmiddel, es kijken. thanks!


ff bijgelezen in de specs staat bewust geen padding strategie:

Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification. If the application layer protocol on top of TLS has its own padding, it may be preferable to pad application_data TLS records within the application layer. Padding for encrypted handshake and alert TLS records must still be handled at the TLS layer, though. Later documents may define padding selection algorithms or define a padding policy request mechanism through TLS extensions or some other means.

Ik zal eens kijken in de implementaties.

Ah, meer over padding en implementaties https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

[Reactie gewijzigd door djwice op 24 juli 2024 16:40]

[WhatsappHack]

Zie ook: reviews: Dns-over-https - Meningen verdeeld over encryptie dns-queries (Al heeft dat artikel wat foutjes)

[TijsZonderH]

Welke foutjes zijn dat?

[Mel33]

Maar is het gevolg daarvan dan niet dat men alleen sites toevoegt die toegestaan zijn door de werkgever?. En dat men alleen protocollen toestaan die echt nodig zijn. Je sluit dan wel heel wat perongeluk downloaden van malware en mails die jou willen phishen uit, je kan daar gewoon dan niet naartoe.
Of is dat niet een gevolg van deze, en snap ik er niks van na het lezen van het stuk van jouw link.
Want het is altijd de gebruiker die het grootste lek is, en dat zet je nu dan anders op in je bedrijf, of kan dat niet zo?

[TechSupreme]

Het enige waar ik me in kan vinden is het commentaar dat maar een handjevol servers het ondersteunen (Cloudflare, Google) en dat je daarmee de decentrale infra gaat centraliseren. Er moeten echt wel meer servers bij komen om het internet gezond te houden. Het "Trusted Recursive Resolver program" is dikke onzin, Mozilla gaat niet voor mij kiezen welke DNS resolver ik ga gebruiken. Ze moeten de DNS instellingen van mijn systeem volgen en als die DoH ondersteunt dan DoH ook gebruiken.

Mozilla gaat geen keuzes voor mij maken, dit gaat me net een stapje te ver.

De rest is echt dikke onzin. Goede blocklistst? Bestaan die dan? Zo zie ik ook niet hoe een adblocker browser plugin zijn werk niet meer zou kunnen doen.

[Vexxon]

Dus de partij die het meest baat heeft bij die third party cookies gaat ze blokkeren? Right...

Waarschijnlijk weten ze dat het percentage van gebruikers die in incognito modus browst dermate laag is dat het niet veel uitmaakt op de hoeveelheid data die ze binnenharken. Of se hebben een andere methode gevonden, bv fingerprinting.
Kortom dit is alleen maar om goodwill te doen en is wederom een wassen neus van Google die zich zogenaamd om de privacy van haar gebruikers bekommert.

[Freeaqingme]

Of ze hebben een andere methode gevonden, bv fingerprinting.

Correct. Iedere chrome-installatie stuurt een x-client-data header mee naar alle Google-domeinnamen welke een tracking code bevat welke uniek is voor jouw installatie. In eerste instantie beweerde Google nog dat dat geen persoonlijke informatie bevatte, later kwamen ze daar deels op terug: https://vpnoverview.com/n...t-contain-pi-information/

Google heeft dus een eigen super cookie, de concurrentie heeft het nakijken.

[Sorcerer8472]

Dit gaat alleen naar Google domeinen? Dat is concurrentievervalsend monopoliegedrag en ook verboden. Los van de privacy issues.

Dat het alleen is om Chrome-ontwikkeling te steunen, leuk dat ze dat zeggen, maar de header gaat ook naar hun ad-domeinen en naar bijv. het YouTube-domein. Of je nou wel of niet ingelogd bent.

Nog wat meer achtergrond:
https://www.theregister.c...google_chrome_id_numbers/

[Reactie gewijzigd door Sorcerer8472 op 24 juli 2024 16:40]

[Freeaqingme]

Ik was er volledig van overtuigd dat Google dit in Incognito modus ook zou doen. Echter, het blijkt dat ze deze _altijd_ meesturen (ook als je cookies blokkeert etc), behalve in Incognito modus. Als je dus per se Chrome wil gebruiken, en niet wil dat Google dit doet, je gewoon altijd in Incognito modus je ding kan doen

Overigens zie ik dat Chromium dit tot voor kort ook gedaan zou hebben, echter kan ik dit op versie 81 niet reproduceren.

[Reactie gewijzigd door Freeaqingme op 24 juli 2024 16:40]

[svenk91]

Chrome heeft geen monopolie op de browser markt. Ze zijn wel heel groot op de browser markt, maar zeker geen monopolist.

[morphje]

Graag vraag ik je de volgende lijst van grote browsers aan te vullen naar market share.

Chrome
Firefox
Safari

Van die lijst is chrome verreweg de grootste, net zoals vroeger IE dat was. IE noemde we ook een monopolist, net zo zeer dat chrome ook een monopolist genoemd kan worden.
(ps. edge is nu ook chrome, legacy edge en IE zijn insignificant en worden niet meer geupdate).

[svenk91]

Chrome heeft iets van 2/3de van de markt als ik mij niet vergis. Voor een monopolie moet je echter zo goed als de enige verkoper/leverancier zijn en zijn er geen acceptabele alternatieve verkopers/leveranciers. Dat is hier simpelweg niet het geval. Zo ver ik weet is Microsoft ook nooit veroordeelt voor een monopolie op IE, enkel voor een monopolie op OS'en (het marktaandeel van Windows in de OS markt was veel groter dan dat van Chrome in de browser markt, en voor zeer veel toepassingen kon je niet om Windows heen).

Edge is trouwens draaiend op dezelfde engine, maar niet hetzelfde als Chrome.


Het is dus simpelweg geen monopolie situatie, voornamelijk een zaak van slechte voorlichting van de gebruikers waardoor ze niet een van de voor hande zijnde acceptabele alternatieven gebruiken (Firefox, maar ook Chromium/Edge).

[morphje]

Microsoft is zeer zeker veroordeeld, ze waren verplicht Windows te leveren zonder afhankelijkheden van IE. (hoewel dat maar ten dele succesvol is geweest). Maar belangrijker is dat ze veroordeeld waren door de gemeenschap (specifiek de power users). Hoeveel jaren zijn daar overheen gegaan voordat er een soort van gezonde concurrentie was?

En dat is ook hier het geval. Google heeft dusdanig veel advertentiegeweld gebruikt om Chrome aan de man te brengen. Nu zitten ze in de positie om wijzigingen door te voeren zonder enige vorm van concensus. Zo hebben ze regelmatig nieuwe elementen toegevoegd buiten de standaarden om, puur om hun eigen agenda te pushen. Firefox heeft dat geweld niet tot hun beschikking en nu Microsoft ook Chrome als core gaat gebruiken is het einde zoek.

Standaarden bestaan voor een reden. *Goede* concurrentie is gezond. In een wereld waar 1 bedrijf hun wil kan opleggen kan je stellen dat het bedrijf een monopolist is. Dat het technisch en juridisch niet zo is volgens de definities, doet niks af aan de intenties en de werkelijkheid. Chrome is de nieuwe IE6, je ziet het alleen nog niet.

"Works best in Google Chrome". Leuke zin en TE vaak gezien, sterker nog het was ook heel vaak "works ONLY in chrome" met een actief non-chrome-blokkeerbeleid in sommige gevallen.

[Reactie gewijzigd door morphje op 24 juli 2024 16:40]

[svenk91]

Eerst hamer je op het belang van standaarden, en dan ga je je eigen verzonnen definitie van monopolie pushen

Ze misbruiken hun sterke marktpositie ja, maar het is geen misbruik van een monopolie positie, want ze hebben geen monopolie volgens de standaard definities van het woord...

Daarnaast zeg ik net zo goed dat MS veroordeeld is als monopolist, enkel dat dat niet was voor een monopolie op de browsermarkt (zoals jij eerder beweerde, maar op de OS markt.

Maar laten we de discussie hier eindigen. Met gesteggel over standard vs. zelf verzonnen definities en begrijpend lezen kan je eeuwig doorgaan natuurlijk.

[morphje]

Dan gaan we even terug naar de originele woordkeuze: concurrentievervalsend monopoliegedrag

En daar loop je op te zeiken. De woordkeuze. Het gedrag is weldegelijk dat van een monopolist. Dat het woord misschien niet correct is, prima. Maar het is wel het beste woord dat aansluit bij het gedrag en de gevolgen. De originele woordkeuze is daarom WEL correct, omdat het juist hetgeen aangeeft dat van toepassing is. Je zou prima in een amerikaanse rechtzaal passen, je weet namelijk precies de aandacht af te leiden van hetgeen dat belangrijk is.

Voor de implementatie van technische zaken zijn standaarden niet ondenkbaar. Daar is geen verschil tussen de letter van het woord en de intentie van het woord. Een technische specificatie kan maar 1 uitkomst hebben. Echter is er in taalgebruik weldegelijk een verschil tussen de letter van het woord en de intentie van het woord. Maar als je dan toch zo graag advocaatje wilt spelen, geef maar een betere woordkeuze die volgens jou 100% zou aansluiten bij het getoonde gedrag. (dwz agressief pushen van de markt, actief "chrome only" beleid, eigen standaarden introduceren, etc etc)

[svenk91]

Ik geef het al aan in de post waar je op reageert 'Ze misbruiken hun sterke marktpositie...'. Ik zou het ook niet persé monopolisten gedrag noemen, genoeg kleine bedrijfjes die ook eigen variaties op standaarden of compleet eigen systemen maken, het is alleen nu een gevaar omdat Chrome een sterke marktpositie heeft.

Door het te framen als 'monopoliegedrag' gaan mensen ook denken dat Google daadwerkelijk een monopolie heeft. Misschien moet ik idd advocaat worden (of ik blijf lekker mijn huidige onderzoek naar marktdynamiek doen als econoom), en dan kan jij de media in.

[Atlantis1995]

Google heeft dus een eigen super cookie, de concurrentie heeft het nakijken.

Kunnen we dat super cookie niet blokkeren op moment die data doorgeeft door een stukje hardware in de lijn?

[Freeaqingme]

Een stukje hardware is lastig. De header wordt verstuurd over een https verbinding, en voor zover ik weet doet Google aan certificate pinning. Je kan dus niet zo maar je verbinding MITM'en om die header er uit te filteren.

Echter, zoals gezegd zag ik het niet terug bij Chromium, de open source variant van Chrome. Dus wellicht dat het makkelijkste is om dat te gebruiken.

Of natuurlijk gewoon Firefox, die lijkt doorgaans veel meer op privacy gefocust te zijn.

[Atlantis1995]

M.a.w. an heb je het certificaat nodig en voer je een men in the middle actie uit.

[Freeaqingme]

Hoe moet dat werken als je browser hardcoded fingerprints van Google's certificaten controleert?

[PhanToM__]

En wat als je een offline installer gebruikt? Als dat nog bestaat...

[Vexxon]

En het mooie is dat ze het als goed nieuws brengen, zo van kijk ons eens jouw privacy beschermen, maar ondertussen is het gewoon een truc om de concurrentie buiten spel te zetten.

[JurGradi]

Dus de partij die het meest baat heeft bij die third party cookies gaat ze blokkeren? Right...

Ik denk dat je dat toch verkeerd ziet hoor. Ze hebben hun reputatie tegen en kunnen gewoon niets goed meer doen. Ik denk dat er ergere spelers op de markt zijn dan Google.

Trouwens waarom zou google third party cookes gebruiken. Veel sites gebruiken Google Analytics ... en dat is geen third party. Dat is gewoon google zelf. En ik denk dat ze daar al veel van de data vandaan krijgen die ze wensen.
Vul dat aan met al wat je zoekt op ... jawel Google (ook geen third party).
Al wat je ziet en zoekt op YouTube ... ook Google dus geen third party.
En dan denk ik dat je het grootste deel van de benodigde data al hebt om een goed profiel van een gebruiker op te bouwen.

Dus neen, ik ben niet van mening dat google diegene is die het meeste baat heeft bij third party cookies.

[Reactie gewijzigd door JurGradi op 24 juli 2024 16:40]

[gedonie]

Google Analytics is juist wel third party. Immers de website die het erop heeft is niet Google. Dus stel Tweakers gebruikt Google Analytics dan zouden de cookies daarvan geblokkeerd moeten worden.

[Maurits van Baerle]

Google zelf harvest wel gewoon je data via Chrome zelf, ook tijdens een incognito sessie. Daar hebben ze geen cookies voor nodig.

Dit is vooral om te zorgen dat partijen die niet Google heten je niet meer kunnen tracken. Ze schakelen de concurrent uit.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 16:40]

[dec0de]

Of ze zien google als een first / second party?

[Sharkoon]

Zucht, alsof Google het ooit goed kan doen. Denk dat je je eerder zorgen moet maken over de vele datalekken van tegenwoordig.

[Anoniem: 1350842]

Waarschijnlijk niet, het TweakersInternet/Reddit/Tech en jongeren social media platforms sentiment is toch wel: Doe 1x iets fout en je bedrijf is voor altijd klaar. Beetje vermoeiend soms, maar je ziet het bij ieder groot bedrijf wat enigszins een reputatie heeft voor dit soort dingen. Zelfs goed nieuws wordt afgeschoten of weggewuivd. Je kunt als Google voor sommige mensen niet zo veel goed doen behalve door ophouden met bestaan (even los van dat diezelfde mensen 0 vermogen hebben om in te zien dat dat ook erg ongunstig zou zijn).

Kritisch zijn mag altijd en is ook goed, maar soms heb ik het gevoel dat het een beetje doorslaat in alles afkeuren omdat er een naamkaartje aan hangt wat mensen niet bevalt.

[Reactie gewijzigd door Anoniem: 1350842 op 24 juli 2024 16:40]

[PD2JK]

Sophos UTM firewall en waarschijnlijk nog veel meer beveiligingspakketten, kunnen proactief (jaja buzzword) botnets en ik weet niet wat blokkeren aan de hand van DNS requests.
Dit werkt dus niet meer en zijn we toevertrouwd aan Google?

[JohnD1]

dns over https zorgt er ook voor dat je geen filtering meer kan doen....
ben er niet blij mee..

[Mushroomician]

Je kunt een DoH proxy zelf hosten.
De inkomende verzoeken kun je filteren naar wens en/of herhalen naar een upstream DoH server van één of meerdere externen. Eventueel met "Round Robin" ivm privacy.
Ook cachen is mogelijk voor allerlei doeleinden, inclusief privacy (je bezoekfrequentie).

In je clientsoftware (browser, OS, welke app dan ook) geef je dan aan een eigen DoH server te willen gebruiken, en die ziet verder geen verschil. (Dan moet deze software die optie wel aanbieden, *kuch Android App kuch*)

[Reactie gewijzigd door Mushroomician op 24 juli 2024 16:40]

[Primuszoon]

Betekent dit dan dat ik op alle toestellen en browsers mijn DNS moet gaan instellen? Nu komt de configuratie via dhcp lekker centraal.

Eigenlijk vind ik dat browsers mijn systeem moeten volgen en niet zelf hun DNS en andere protocol instellingen moeten gaan uitvinden...

[Mushroomician]

De optie om de standaard systeeminstellingen te gebruiken blijft er waarschijnlijk wel in. In iedergeval op de desktop. Of dat ook bij de mobiele apps zo is durf ik niet te zeggen, ivm de hype van beperkte instellingenmenu's.

[Wim-Bart]

Wanneer je goed leest, dan zie je wanneer jouw DNS provider, dus de gene welke via DHCP wordt ingesteld, DoH aanbied, dan wordt het ingeschakeld.

Heb je dus een PiHole draaien dan is er niks aan de hand. Het wordt leuk voor mensen die 8.8.8.8,1.1.1.1,8.8.4.4 gebruiken.

[Bor]

For now. Er is geen enkele garantie dat dit zo blijft werken en gezien DoH niet door het OS wordt geregeld maar in de applicatie kan dit per product verschillen. Geen wenselijke of beheerbare situatie.

[Bor]

De zaken die je noemt zijn allemaal lapmiddelen die niet of maar half werken. Caching is niet bedoelt (en ook erg ineffectief) als privacy maatregel, round robin opstellingen evenmin. Een DoH proxy moet worden ondersteund wat AFAIK meer niet dan wel het geval is. Het aantal DoH DNS servers is daarbij dungezaaid en veel software blijft maar proberen om naar de server van de aangewezen leverancier te verbinden. Het hele protocol zit zo in elkaar dat je maar weinig invloed hebt als bedrijf zijnde.

[Mushroomician]

Klopt, een DoH proxy van een vertrouwde partij geeft dan wel meer privacy dan een eigen proxy met een onbetrouwbare uplink. Die uplink is waar het om gaat.

Dat ieder stukje software straks een eigen DoH implementatie gaat implementeren staat gelijk aan het complete DNS-systeem fragmenteren en is een ondermijning van het hele internet hyrarchie. Een domein bezitten staat dan gelijk aan het hebben van een app. Gevolg is dat websites verdwijnen en native-apps de norm worden.

Voorbeeld: Ik publiceer een app in de store met de naam Frutti Tutti. FT bevat voor API-calls dns instellingen naar mijn eigen DoH server. In mijn server registreer ik google.com als eigendom. Al het verkeer binnen FT gericht naar Google.com komt bij mij terecht: Slaat nergens op, geeft geen gevaar voor andere apps, en is compleet nutteloos, maar het kan wel.

[Reactie gewijzigd door Mushroomician op 24 juli 2024 16:40]

[curkey]

Ik zat net te denken om iets a la pi-hole te gaan installeren, maar als ik jouw antwoord zo lees, moet ik daar dus nog wat aan toevoegen willen dit soort clients daarvan gebruikmaken? Of is dit iets wat pi-hole al van zichzelf kan doen?

[Wim-Bart]

Met PI-hole als DNS server wordt DoH uitgeschakeld.

[Bor]

In de huidige Google implementatie wellicht. Niets staat in de weg om dat later aan te passen of niets verplicht andere aanbieders om hetzelfde te doen.

[Wim-Bart]

Klopt, maar we praten over nu en niet over 10 jaar. Misschien zie jij de wereld ook totaal anders over een half jaar of 10 jaar.

Maar nu blijven zaken dus gewoon werken zoals het moet werken. Firefox daar in tegen moet je hele andere maatregelen voor treffen, je moet daarvoor zelfs een speciale dns zone inrichten in je omgeving. Dat is veel zorgelijker.

Het enige wat je nu nog kan doen is actief verkeer gaan blokkeren naar DoH servers. Echter kan nu iedere applicatie dit implementeren naar servers waarvan je geen weet hebt en er niks anders op zit om weer met de oude vertrouwde proxy servers te gaan werken of DPI te doen met in- en uitpakken van verkeer.

DoH, in tegenstelling tot DoT, is de doos van Pandora. En in mijn beleving uitgevonden om ad-blockers, Pi-Hole en andere maatregelen dwars te zitten en nutteloos te maken.

Heb zelf nu thuis bijvoorbeeld actieve blokkades in firewall naar diverse DoH servers. Gewoon IP geblokkeerd. En wanneer je ziet wat dit allemaal raakt.....

[Anoniem: 767041]

Nextdns.io gebruiken

[Anoniem: 1350842]

Maar het is een optie die je uit kunt zetten. De overgrote meerderheid van mensen met een PC doet niks met filteren, of weet uberhaupt wat een DNS server is. Die mensen hebben wel degelijk baat bij een dienst die zonder stappen de beveiliging verbeterd. Mensen die dat niet willen zetten het uit, maar als je bezig bent met DNS filtering kun je wel verwachten dat die mensen ook een instelling in Chrome wel uit krijgen.

[ScorcH]

Nee, het gaat naar je DNS provider, wat je gewoon zelf kan zijn.

[Pizzalucht]

Google begint de komende tijd ook met de uitrol van dns-over-https of DoH. Daarbij worden dns-queries versleuteld via ssl. Chrome kijkt dan eerst of de huidige dns-provider dns-over-https aanbiedt. In dat geval wordt DoH automatisch ingezet. Anders blijven de bestaande dns-instellingen actief.

[OptimalApex]

Wordt helaas je internetervaring trager van

[Jazco2nd]

Je hoeft nieteens een expert te zijn om te beseffen dat DoH buiten de US vrijwel niks oplevert.
Alleen de verbinding tussen jou en de eerste DNS provider is versleuteld, alles daarna niet. En die DNS provider zal dus jouw verzoek onversleuteld doorsturen naar andere nameservers om het IP adres dat je zoekt te achterhalen.

Een veel betere oplossing is Recursive DNS. Dit kan je doen door zelf Unbound te draaien op je NAS, RaspberryPi of homeserver. Evt icm PiHole.

Binnen de VS heeft DoH wel een nuttig voordeel omdat ISPs daar legaal en volkomen geaccepteerd (door de FCC) handelen in browserhistorie met adverteerders. Door DoH standaard in de browser te zetten beschermde Mozilla Amerikanen hiertegen en nu ook Google. Je kon het ook oplossen door een andere DNS provider in je router of device in te stellen, maar dat doet de massa niet zo gauw.

[Reactie gewijzigd door Jazco2nd op 24 juli 2024 16:40]

[MaffeMaarten]

Al deze features komen me bekend voor

Ik denk zelf dat hier precies mee duidelijk wordt gemaakt wat het belang van FireFox tegenwoordig is.
Tuurlijk, FF heeft al heel lang geen heel groot marktaandeel meer, maar ze zijn nog steeds groot genoeg om voorop te lopen in privacy dingen en opgemerkt te worden.

Als andere browsers hier niet mee begonnen waren, had Chrome dit nu nooit gehad.

[Mel33]

Het heet indirecte cookies hier in chrome 81.0.4044.138, ik geloof dat 3rd party nog steeds gewoon kan dan. Kweet niet hoe het in engels staat, (ik snap ook dat indirect ook 3rd party kan zijn, maar ik geloof dat er toch een verschil is nu heden ten dagen in google zijn ogen).

[Reactie gewijzigd door Mel33 op 24 juli 2024 16:40]

[twizzle]

Google kan onmogelijk eigen third party cookies niet als dusdanig kenmerken dat zou een enorme tik op de vingers opleveren juridisch gezien

[R20141016]

Ik noem de 'incognito' modus altijd de 'porn' modus.
Maar ik gebruik hem nooooooit

[arnoudx6]

Kan iemand uitleggen waarom het handig zou zijn om het HTTPS protocol hiervoor te gebruiken? DNS verkeer is naar mijn idee vrij simpel verkeer en heeft de overhead van HTTP niet nodig. Het gebruik van TLS kan ik begrijpen, maar waarom wordt DNS verkeer dan niet gewoon over een TLS verbinding gestuurd (Zonder de overhead van het HTTP protocol)?

Ook zit je bij HTTPS met TCP verkeer wat meer roundtrips heeft dan UDP. Een poos geleden las ik iets over het QUIC protocol wat encryptie over UDP verkeer faciliteert. Is QUIC dan niet precies wat we zoeken omdat er minder roundtrips zijn dan bij TCP verkeer.
https://en.wikipedia.org/wiki/QUIC