image

Onderzoekers ontwikkelen privacyvriendelijke dns-oplossing

maandag 9 april 2018, 15:32 door Redactie, 7 reacties

Onderzoekers hebben een dns-oplossing ontwikkeld die de privacy van internetgebruikers moet beschermen. Het domain name system (dns) is vergelijkbaar met het telefoonboek en vertaalt onder andere domeinnamen naar ip-adressen. Standaard maken internetgebruikers gebruik van de dns-servers van hun internetprovider. Die kan echter zien welke websites hun abonnees opvragen.

Nu zijn er alternatieve dns-aanbieders zoals CloudFlare, Google, OpenDNS en Quad9. In dit geval gaan de dns-verzoeken naar de alternatieve dns-aanbieder. Dit houdt echter in dat de gebruiker deze partij moet vertrouwen. Daarnaast zijn dns-verzoeken meestal onversleuteld en bevatten die informatie zoals de website die de gebruiker bezoekt, het ip-adres of subnet van het apparaat waar het verzoek van afkomstig is en zelfs de soorten apparaten die een gebruiker in zijn of haar thuisnetwerk heeft staan, aldus onderzoekers van de Princeton University.

Er zijn wel oplossingen om de privacy te verbeteren, zoals dns over tls waarbij dns-verzoeken worden versleuteld, maar die lossen niet het fundamentele probleem van dns-privacy op. Namelijk dat de dns-server kan zien dat een bepaald ip-adres een website opvraagt. De onderzoekers hebben daarom een oplossing bedacht genaamd "Oblivious DNS" (ODNS). ODNS functioneert net als het normale dns, maar heeft twee extra onderdelen.

Elke client draait een lokale ODNS-stubresolver en er wordt een zogeheten "ODNS authoritative zone" toegevoegd die ook als dns-resolver fungeert. Wanneer bijvoorbeeld de browser van een gebruiker het ip-adres van een website wil opvragen, zorgt de lokale stubresolver ervoor dat de opgevraagde domeinnaam geobfusceerd is. Zodoende weet de recursive dns-server niet welk domein er wordt opgevraagd. De authoritative nameserver voor ODNS verwijdert de identiteit van de gebruiker uit zijn dns-verzoek, zodat de uiteindelijke nameserver niet weet wie het ip-adres van een bepaald domein opvraagt.

In de praktijk werkt dit als volgt. De browser van de gebruiker wil de website foo.com opvragen. De stubresolver genereert een sessiesleutel "k", versleutelt het opgevraagde domein en voegt de tld-extensie .odns toe. Dit resulteert in {foo.com}k.odns. De browser stuurt dit verzoek met de sessiesleutel naar de recursive resolver, die het doorstuurt naar de authorative nameserver voor .odns. Deze ODNS-nameserver ontsleutelt de sessiesleutel met de eigen privésleutel en ontsleutelt vervolgens het opgevraagde domein met de sessiesleutel.

De ODNS-nameserver stuurt vervolgens een dns-verzoek naar de nameserver van foo.com. Deze server stuurt het antwoord naar de ODNS-nameserver terug. De ODNS-nameserver versleutelt dit antwoord, dat de domeinnaam foo.com en het ip-adres, en stuurt het terug naar de gebruiker. Zijn stubresolver kan vervolgens zowel het domein als het ip-adres ontsleutelen. De onderzoekers hebben nu een eerste prototype gemaakt waaruit blijkt dat ODNS 10 tot 20 milliseconden aan elk dns-verzoek toevoegt. Aangezien dns gebruik van caching maakt verwachten de onderzoekers dat de impact in de praktijk kleiner zal zijn. Er wordt nu aan een grootschaliger prototype gewerkt, waar ook partners voor worden gezocht.

Image

Reacties (7)
09-04-2018, 16:52 door Anoniem
09-04-2018, 18:13 door karma4
Daarna gaat het verkeer door via de verkregen ip nummers. Net zo kenmerkend of zelfs nog beter dan het dns naampje.
09-04-2018, 19:10 door Anoniem
Door karma4: Daarna gaat het verkeer door via de verkregen ip nummers. Net zo kenmerkend of zelfs nog beter dan het dns naampje.


mispoes (as usual):

https://en.wikipedia.org/wiki/Virtual_hosting
10-04-2018, 00:07 door Briolet
Door Anoniem:
Door karma4: Daarna gaat het verkeer door via de verkregen ip nummers. Net zo kenmerkend of zelfs nog beter dan het dns naampje.


mispoes (as usual):

https://en.wikipedia.org/wiki/Virtual_hosting

En hoe denk je dat virtual hosting werkt? De domeinnaam op dat IP staat in de http(s) header. Die naam kan nog niet gecodeerd zijn, want op dat moment weet het pakket nog niet welke website (dus ook certificaat) er achter zit.

Oftewel: De provider heeft helemaal niet de dns server nodig om te zien met welke website je verbindt.
10-04-2018, 10:43 door Anoniem
Door Briolet:
Door Anoniem:
Door karma4: Daarna gaat het verkeer door via de verkregen ip nummers. Net zo kenmerkend of zelfs nog beter dan het dns naampje.


mispoes (as usual):

https://en.wikipedia.org/wiki/Virtual_hosting

En hoe denk je dat virtual hosting werkt? De domeinnaam op dat IP staat in de http(s) header. Die naam kan nog niet gecodeerd zijn, want op dat moment weet het pakket nog niet welke website (dus ook certificaat) er achter zit.

Oftewel: De provider heeft helemaal niet de dns server nodig om te zien met welke website je verbindt.

Precies, er is door je ISP altijd te achterhalen met welke sites je verbinding maakt. Ik zie nog wel een kansje voor VPN+ODNS.
10-04-2018, 20:15 door Anoniem
Door Briolet:
Door Anoniem:
Door karma4: Daarna gaat het verkeer door via de verkregen ip nummers. Net zo kenmerkend of zelfs nog beter dan het dns naampje.


mispoes (as usual):

https://en.wikipedia.org/wiki/Virtual_hosting

En hoe denk je dat virtual hosting werkt? De domeinnaam op dat IP staat in de http(s) header. Die naam kan nog niet gecodeerd zijn, want op dat moment weet het pakket nog niet welke website (dus ook certificaat) er achter zit.

Oftewel: De provider heeft helemaal niet de dns server nodig om te zien met welke website je verbindt.

niet zonder deep packet inspecties waarbij de ip pakketen tot op het http protocol over tcp op headers on the fly door je provider op elke nieuwe verbinding naar een poort 80. dat kost resources, en dat vergeleken bij een dns lookup direct naar de provider dns veel eenvoudiger en goedkoper dus gaat.

detail vwb https: de rsa handsake moet volbracht zijn voordat de http header (server side) bekend is en om de rsa handshake te voltooien heb je een cert voor een domein als client al moeten accepteren en had de server dus al het juiste cert met juiste domein naam aan je moeten aanbieden voordat je als client http headers begon te sturen.

https://wiki.apache.org/httpd/NameBasedSSLVHosts

het originele punt is daarom ook: omdat je nogal wat virtual hosting hebt over http, is het ip nummer van een server waartoe een verbinding gemaakt wordt niet zo veel zeggend over het domein dat bezocht wordt. een eigen dns gebruiken of een derde ontneemt je ISP de super eenvoudige mogelijkheid om bij te houden welke domeinen jij bezoekt. dus meer veligheid. meteen 100% super veilig en aan alles gedacht? nope, maar wel een stukje veiliger dus.

zie het maar als een gapend gat van 1 meter diameter dat naar een gaatje van een halve centimeter gaat. relevant en de moeite waard door een eenvoudige instelling. en ja dat gaatje van 1 cm blijft er nog, maar hee, das 99 cm minder en een stuk minder dwijlen of hozen :). praktisch werkbaar misschien wel ineens maar uiteraard nog steeds niet perfect.
12-04-2018, 12:50 door Anoniem

niet zonder deep packet inspecties waarbij de ip pakketen tot op het http protocol over tcp op headers on the fly door je provider op elke nieuwe verbinding naar een poort 80. dat kost resources, en dat vergeleken bij een dns lookup direct naar de provider dns veel eenvoudiger en goedkoper dus gaat.

Inspection van HTTP(S) om hostname/URL/parameters te verifiëren is veel minder arbeidsintensief dan alle DNS verkeer te controleren. Dit komt wegens het grote verschil in quantiteit..

Case in point: Veel bedrijven gebruiken een IDS/IPS voor HTTP(S) inspection, maar DNS wordt niet gecontrolleerd omdat er gewoonweg meerdere magnitudes meer DNS requests zijn dan HTTP(S) requests.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.