Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

'Domeinvalidatie van bepaalde CA's is om de tuin te leiden via dns-aanval'

Onderzoekers van het Duitse Fraunhofer SIT-instituut claimen dat de domeinvalidatie van bepaalde grote certificaatautoriteiten kwetsbaar is voor cache poisoning van de dns-cache, waardoor een aanvaller een certificaat voor het domein van een ander kan verkrijgen.

De onderzoekers hebben hun bevindingen beschreven in een paper die ze gedeeld hebben met The Register en Heise. Omdat verschillende autoriteiten nog kwetsbaar zouden zijn, hebben ze de namen van de organisaties niet openbaar gemaakt. De sites schrijven dat een aanvaller met deze methode in staat is een digitaal certificaat voor een domein te verkrijgen van een andere partij. Vervolgens is het bijvoorbeeld mogelijk een kwaadaardige nepsite in het leven te roepen, die voor bezoekers over het juiste certificaat lijkt te beschikken.

De aanval maakt gebruik van cache poisoning op basis van ipv4-fragmentatie, aldus Heise. Dat is geen nieuwe techniek. Het zou daarvoor niet nodig zijn om actief netwerkpakketten te onderscheppen. The Register citeert uit het onderzoek: "De aanval begint met een dns-verzoek. Om de aanval te laten slagen, moet de aanvaller een juist dns-antwoord zien op te stellen voordat het daadwerkelijke antwoord van de echte dns-server aankomt." Door de dns-pakketten 'op te breken' in twee delen, kan de aanvaller valse ip-adressen in de dns-cache laten opnemen.

Domeinvalidatie is een manier waarop certificaatautoriteiten controleren of een partij daadwerkelijk de eigenaar is van een domein. Dit gebeurt doorgaans geautomatiseerd. Onderdeel van het proces kan bijvoorbeeld het aanmaken van een txt record zijn. Er zijn ook andere methodes die meer eisen stellen, zoals extended validation. De onderzoekers hebben hun eigen variant van domeinvalidatie voorgesteld onder de naam DV++, die resistent moet zijn tegen hun aanval. Die willen ze presenteren op de komende ACM-conferentie in Canada. Dnssec zou ook een effectieve verdediging zijn.

Door Sander van Voorst

Nieuwsredacteur

10-09-2018 • 11:10

47 Linkedin Google+

Reacties (47)

Wijzig sortering
Voor Nederlandse overheden zou dit (binnenkort en als men zich aan de wet houdt) geen probleem mogen zijn, o.a. DNSSec wordt verplicht in de nieuwe Wet digitale overheid die nu in de tweede kamer ligt. En het staat al jaren op de 'pas toe of leg uit waarom niet'-lijst.
Op zich ja..practisch gezien is DNSSec een draak om operationeel te houden met sleutelmanagement. Als het fout gaat is meteen je hele domein niet meer bereikbaar (zie live demo van een DNSSec ontwikkelaar die zijn sleutels wil vernieuwen en het verkloot).

Dat is best wel een groot risico voor een organisatie die het moet hebben van bereikbaar zijn op het internet en ik snap best dat er een hoop organisaties zijn die het operationele beschikbaarheid risico belangrijker vinden dan het potentiële misbruik van DNS cache poisoning.
Op zich ja..practisch gezien is DNSSec een draak om operationeel te houden met sleutelmanagement. Als het fout gaat is meteen je hele domein niet meer bereikbaar (zie live demo van een DNSSec ontwikkelaar die zijn sleutels wil vernieuwen en het verkloot).
Het is wel zo, maar dat geldt tot op zekere hoogte voor iedere beveiligingsmaatregel. Als je je huissleutel verliest dan kom je je eigen huis niet meer in. Als je de private key van je webserver weggooit is je website onmiddellijk onbereikbaar. Als je SSH-key verloren gaat dan werkt SSH niet meer.
Het zou al een hoop helpen als mensen reserve-sleutels publiceren en die in de brandkast bewaren voor noodgevallen, net zoals je met wachtwoorden en certificate.

Het belangrijkste verschil is dat we nog maar weinig ervaring met DNSSEC hebben. Daarnaast hebben we er een gewoonte van gemaakt om regelmatig onze DNSSEC-keys te verversen. Dat is een gewoonte, geen technische eis, net als het regelmatig vervangen van je wachtwoorden een SSL-certificaten. Dat wisselen is een gevoelige operatie die technisch nog niet goed wordt ondersteund.

Hier komt het grootste technische verschil om de hoek: DNSSEC doe je niet op één plaats, maar op (minstens) twee: namelijk op je eigen (authorative) DNSSEC-servers én bij de DNS-servers van je parent-domein. Die communicatie is waar het nu vaak fout gaat. Mensen weten niet dat het nodig is, weten niet hoe, of, vaker dan niet, kunnen het proces niet automatiseren. Zolang DNSSEC in praktijk betekent dat je met de hand cryptografische sleutels moet kopieren naar een tekstveldje op de website van je DNS-boer blijft het problematisch. Er zijn wel wat standaarden en protocollen opgesteld om dit stuk te automatiseren maar er is nog geen met brede ondersteuning.

Die problemen zijn wel vervelend, maar wel vrij overzichtelijk en oplosbaar. Het veranderen van wachtwoorden en SSL-certificaten hebben we ook betrouwbaar gemaakt met procedures, controles en recovery-mechanismes.

De protocollen om het vernieuw dan DNSSEC-keys te automatiseren staan klaar, de industrie moet alleen nog kiezen welk systeem het beste is en dat breed implementeren, dat begint dichtbij te komen, alle grote partijen zijn er in ieder geval mee bezig.
Geweldige software, maak ik veel gebruik van, maar het kan niet automatisch je keys uploaden naar een provider. Er zijn wel hooks om je eigen upload-scriptje aan te hangen, maar dat is afhankelijk van je DNS-register en/of -registrar. Veel DNS-providers hebben wel een API, en met wat geluk ondersteunt die ook DNSSEC, maar daar zal je zelf wat voor moeten programmeren.
Er zijn standaarden, zoals een uitbreiding op EPP, maar die worden nog maar beperkt ondersteund.
Extra "interessant" is het als je DNS-servers gehost worden door een andere (derde) partij dan waar je domeinen afneemt, want dan moeten die twee onderling de sleutel moeten versturen. Groot feest om dat geregeld te krijgen.
Het werkt wel als je DNS provider een slave-zone ondersteund.
Dan kun je de master server (=je eigen DNS server inrichten naar smaak met alle toeters en bellen) en vervolgens de zone uit laten serveren via de ("slave"-) servers van de DNS provider

Het bulk uploaden van losse name updates kan idd. kostbaar worden.
[...]
Hier komt het grootste technische verschil om de hoek: DNSSEC doe je niet op één plaats, maar op (minstens) twee: namelijk op je eigen (authorative) DNSSEC-servers én bij de DNS-servers van je parent-domein. Die communicatie is waar het nu vaak fout gaat. Mensen weten niet dat het nodig is, weten niet hoe, of, vaker dan niet, kunnen het proces niet automatiseren. Zolang DNSSEC in praktijk betekent dat je met de hand cryptografische sleutels moet kopieren naar een tekstveldje op de website van je DNS-boer blijft het problematisch. Er zijn wel wat standaarden en protocollen opgesteld om dit stuk te automatiseren maar er is nog geen met brede ondersteuning.
Het manueel copy/pasten blijft nodig voor het verkrijgen van de eerste key, en zonder key geen DNSSEC... Automatiseren lijkt mij dan ook niet mogelijk, tenzij je de eerste domeinvalidatie zonder DNSSEC-beveiliging laat verlopen... Kip of ei :)?

Toch even vermelden dat de recentere versies van certbot (de referentie-implementatie van Let's Encrypt) een plugin heeft voor DNS validatie die werkt met de meest voorkomende DNS-servers. Ik heb deze nu draaien voor Bind9 en het lijkt goed (automatisch) te werken voor vernieuwing van de certificaten.
Het manueel copy/pasten blijft nodig voor het verkrijgen van de eerste key, en zonder key geen DNSSEC... Automatiseren lijkt mij dan ook niet mogelijk, tenzij je de eerste domeinvalidatie zonder DNSSEC-beveiliging laat verlopen... Kip of ei :)?
De eerste key is inderdaad het lastigste.
Een mogelijkheid is dat je de key aanlevert op het moment dat je het domein registreert.
Het regisreren en beheren van DNS is bij veel leveranciers al geautomatiseerd, DNSSEC kan daar op zich prima bij. De servers van de leverancier genereren automatisch een key, configuren die in het domein, en voegen hem toe aan de aanvraag.
Als je het direct regelt hoeft dat niet zo moeilijk te zijn. Er is ook al een standaard om domeinen automatisch te verhuizen zonder DNSSEC uit te schakelen.
Op dit moment is het erg belangrijk dat DNS-leveranciers het beheer van DNSSEC via een API mogelijk maken. Het liefst op een standariseerde manier.
Toch even vermelden dat de recentere versies van certbot (de referentie-implementatie van Let's Encrypt) een plugin heeft voor DNS validatie die werkt met de meest voorkomende DNS-servers. Ik heb deze nu draaien voor Bind9 en het lijkt goed (automatisch) te werken voor vernieuwing van de certificaten.
Die gebruik ik ook en ik ben er zeer tevreden mee. Voor deze techniek is DNSSEC ook erg belangrijk, de verificatie is helemaal afhankelijk van de vertrouwbaarheid van DNS.

Er nog een interessant alternatief voor CACert (en de meeste andere certificaten). Als je dan toch al helemaal op DNS vertrouwt, dan kun je ook (een fingerprint van) je SSL-certificaten in DNS publiceren. Dat heet DANE (DNS-based Authentication of Named Entities).
In plaats van dat applicaties controleren dat een SSL-certificaat ondertekend is door een van de bekende CA's, controleren ze nu of het SSL-certificaat overeenkomt met wat er in DNS staat.
In plaats van dat de CACert-bot langs komt om je DNS te controleren, laat je het de clients zelf doen. Ze moeten toch al een keer je DNS-server bevragen om je IP-adres te vinden dus dan kun je direct de DANE-informatie meesturen.
Aangezien de CA's in dit hele verhaal niet nodig zijn kun je ook een self-signed certificaat gebruiken.
Maar dan is er dus ook geen CA die een cerificaat kan revoken?
Om te revoken haal je het record uit DNS, en zodra de TTL verlopen is wordt het certificaat ongeldig.
Ja, daarmee kan de eigenaar het zelf revoken. Maar normaal kan ook de CA het certificaat revoken.

Maar met DANE kies je als gebruiker er blijkbaar voor de DNS te vertrouwen. Op zich niet per se verkeerd, normaal vertrouw je immers zonder het te weten de root CA's die jouw browserbouwer in de browser heeft opgenomen.
Ja, daarmee kan de eigenaar het zelf revoken. Maar normaal kan ook de CA het certificaat revoken.

Maar met DANE kies je als gebruiker er blijkbaar voor de DNS te vertrouwen. Op zich niet per se verkeerd, normaal vertrouw je immers zonder het te weten de root CA's die jouw browserbouwer in de browser heeft opgenomen.
Waarom zou ik willen dat een CA mijn certificaat intrekt als ik het ook zelf kan doen?

Het ligt misschien een beetje aan wat je van een CA verwacht. Het beeld bestaat dat CA's allerlei controles doen voor ze een certificaat uitgeven. In praktijk valt dat nogal tegen, een certificaat zegt over het algemeen niks over de betrouwbaarheid van de eigenaar. Certificaten gebruik je op internet om te zorgen dat je niet wordt afgeluisterd, niet om de identiteit van de eigenaar vast te stellen.
Zorgen dat je niet afgeluisterd wordt kan prima via DANE.

PS. Er zijn ook andere soorten certificaten met meer controles en DANE is dan niet toereikend, maar de bulk van internet draait op eenvoudige certificaten die prima werken via DAN.
Dat klinkt wel handig. Waarom gebruiken we niet allemaal al DANE?
Omdat het nog vrij nieuw en in ontwikkeling is. Nog lang niet alle software kan het gebruiken.
"zie live demo van een DNSSec ontwikkelaar die zijn sleutels wil vernieuwen en het verkloot"

Waar doel je hiermee op?
Ik vermoed dat hij daarmee bedoeld dat het zo een draak is, dat zelfs de ontwikkelaars zelf er fouten mee maken. Dat het in een live demo gebeurd is dan natuurlijk erg lullig.

@Ar0xA De vraag is of je dat nog wel kan in deze staat van technische ontwikkeling en juridische aansprakelijkheid. In de EU worden nu al bedrijven beboet als men een datalek veroorzaakt omdat je security danig niet op orde heb. Wat als dit wordt gebruikt om inderdaad een datalek te veroorzaken doordat een beheerder inlogt of een gebruiker met veel rechten op een webapplicatie waar veel gebruikers gegevens inzitten. Nu is in de praktijk daar nog niemand voor beboet (voor zover ik weet), maar dat heeft meer met de capaciteit te maken van de controlerende instanties.

Je zou dit imho redelijk simpel kunnen oplossen, gebruik twee domein en zorg dat ze nooit tegelijkertijd vernieuwt moeten worden. Dat maakt het lastiger en mogelijk begint de marketing afdeling te stijgeren, maar het zorgt er wel voor dat je nooit door 1 fout meteen niet meer bereikbaar bent. Daar komt bij dat als je nu al een fout maakt met DNS zonder dat daar DNSSEC aan hangt, je domein ook gewoon niet bereikbaar is.

Tweakers.net zou dan als tweede operationeel domein bv. tweakers.nl gebruiken.
Je zou dit imho redelijk simpel kunnen oplossen, gebruik twee domein en zorg dat ze nooit tegelijkertijd vernieuwt moeten worden. Dat maakt het lastiger en mogelijk begint de marketing afdeling te stijgeren, maar het zorgt er wel voor dat je nooit door 1 fout meteen niet meer bereikbaar bent. Daar komt bij dat als je nu al een fout maakt met DNS zonder dat daar DNSSEC aan hangt, je domein ook gewoon niet bereikbaar is.
Je kan vrijwel hetzelfde bereiken met maar één domein.
Zorg dat je twee onafhankelijk DNS-servers hebt die allebei hun eigen DNSSEC-keys aanmaken en uploaden naar de TLD, en die elkaars sleutel cross-signen.
Je moet er alleen voor zorgen dat ze niet tegelijkertijd wisselen en dat ze niet aan elkaar sleutelmateriaal gaan zitten. Zolang één van de twee servers blijft werken is er niks aan de hand.
Die capaciteit wordt (bewust - uiteraard, want beleidsmatig, en dus ook opzettelijk-) volkomen ontoereikend gebudgetteerd door de nationale overheid. De reden voor het feit dat er weinig boetes worden uitgedeeld is dus pure onwil vanuit primair de recente coalities en daarbij opposities die ofwel héél diep sliepen ofwel erin meegingen.

Hier stond veel meer (~ een pagina onderbouwing).
Doch; #SocialCooling ;(

-Dit is een helaas niet geautomatiseerde edit op Tweakers. Ik raad iedereen aan óók zijn of haar best te doen op het internet.. Want het kan zomaar te laat blijken ;)

[Reactie gewijzigd door BStorm op 11 september 2018 15:50]

(zie live demo van een DNSSec ontwikkelaar die zijn sleutels wil vernieuwen en het verkloot).
Heb je een link?
In dat geval zou het voor .nl domeinen eigenlijk nooit een probleem mogen zijn. Vrijwel iedere (gerespecteerde) nederlandse domeinaanbieder biedt standaard DNSSEC aan op .nl domeinen. Het jammere is alleen dat vrijwel geen enkele resolver ook daadwerkelijk een DNSSEC verificatie doet. Of CA's dat nu al wel doen, durf ik niet te zeggen. Maar anders zullen ze dat hopelijk snel integreren nu.
Dit oude artikel geeft aan dat de root servers het al effe doen.

Zelf gebruik ik pihole + unbound, met DNSSEC enabled in unbound.

Heb een hele tijd gepoogd dit door pihole (dnsmasq2.79 of de fork pihole-FTL - based on dnsmasq2.79) te laten afhandelen maar er zijn teveel problemen met de implementatie van DNSSEC om het betrouwbaar te laten werken. Die problemen zouden opgelost moeten zijn in dnsmasq2.80 maar helaas is de stable release nog niet beschikbaar. Heb een en ander getest met de test vesies van dnsmasq, met de laatste test versie lijken die problemen opgelost te zijn.
Hier geen DNSSEC probleem met pihole en unbound.
(net nog getest op internet.nl)

[Reactie gewijzigd door pe0mot op 10 september 2018 12:57]

DNSSEC validatie door dnsmasq of door unbound?
Wanneer de validatie gebeurd door unbound heb ik ook geen problemen, zodra de validatie gebeurd door dnsmasq komen de problemen te voorschijn. Nadeel van validatie door unbound is natuurlijk dat DNSSEC uit de pihole web interface verdwijnt.

De problemen, die ik opmerkte, kwamen vooral aan het licht, bij gebruik van DNScrypt-proxy-v2. Ik ben uren bezig geweest, in samenwerking met de developer van dnsmasq (Simon Kelley), die uiteindelijk ook DNScrypt-proxy heeft geinstalleerd, om die problemen op te lossen.

Hier een topic waarin een en ander uit de doeken gedaan is, maar dit is zeker geen alleenstaand topic, zoek op DNSSEC in discourse
Inderdaad in unbound als resolver. Is ook logischer aangezien deze door ons nlnet vrienden is uitgebracht.
https://nlnetlabs.nl/projects/unbound/about/
DNSSEC komt ook uit deze stal.
Via dnsmasq en wel of niet een externe resolver heeft bij mij minder vertrouwen ;)

[Reactie gewijzigd door pe0mot op 10 september 2018 14:42]

Hou je dit ook in de gaten, dnsmasq heeft een handmatige update nodig:
https://www.sidn.nl/a/ken...ieuwe-dnssec-trust-anchor
Bij unbound is dat autoupdate _/-\o_

[Reactie gewijzigd door pe0mot op 11 september 2018 15:18]

Zou het niet beter zijn als de certificaatautoriteiten DNSSEC verplichten bij een DNS validatie?
DNSSEC verplichten zal, denk ik, nooit mogelijk zijn omdat er alternatieve oplossingen mogelijk zijn.

Een en ander is beschreven in dit artikel, waarbij o.a. DNS cookies (RFC 7873) als alternatief mogelijk worden gemaakt
DNSSEC verplichten zal, denk ik, nooit mogelijk zijn omdat er alternatieve oplossingen mogelijk zijn.

Een en ander is beschreven in dit artikel, waarbij o.a. DNS cookies (RFC 7873) als alternatief mogelijk worden gemaakt
DNS-cookies en DNS-over-TLS lossen maar een deel van de problemen op die DNSSEC oplost. Deze technieken helpen bijvoorbeeld niet als je DNS-resolver niet te vertrouwen is en opzettelijk liegt of blokkeert.
Deze technieken zijn nuttig, ook als je wel DNSSEC hebt, maar ze zijn niet echt een alternatief.

Het implementeren van deze technieken is makkelijker dan DNSSEC, maar staat wel nog in de kinderschoenen. Het zal nog heel wat jaren duren voor je er breed op kan vertrouwen.
Een ook in DNSSec zullen ze bugs vinden, die we ons misschien op dit moment niet kunnen voorstellen.
Dat mag ons niet tegen houden bekende bugs op te lossen. Wat dat betreft is het natuurlijk altijd kat en muis.
Nee, dat mag ons zeker niet tegen houden, om het te verbeteren.
Ik wil alleen maar duidelijk maken, X in ruilen voor Y, geen garantie is.

Zie de afgelopen 20 jaar, de mensen steeds creatiever worden, met systemen te hacken.
Dus ik maak mijn borst nat, voor wat ze o.a. met DNSSec gaan bedenken.
DNSSEC is geen vervaning van DNS, maar een uitbreiding waarbij de antwoorden ondertekend zijn.
Waarbij vanuit de root servers de juiste kloppende endpoints gevonden kunnen worden.

Tenzij de aanvaller even de gehele DNS infra me simuleert met de JUISTE fake antwoorden... dat zal een hels karwij worden.
kan je eventueel aangeven waar ik de wettekst, betreffende DNSSEC kan vinden?

Ik heb in mei 2018 een vraag gesteld aan de minister van digitale agenda (BE) en kreeg van een medewerker het antwoord dat het al veilig genoeg was, ze DNSSEC niet overwegen omdat het te moeilijk is, veel manuren vereist en er niet voldoende kennis beschikbaar is.

Misschien bedenkt hij zich, wanneer hij ziet dat het in NL wel kan...
De "Wet Digitale Overheid" is er nog niet, het is nog een wetsvoorstel, maar je kan de tekst hier vinden:
https://www.tweedekamer.n...&qry=wetsvoorstel%3A34972

De term "DNSSEC" zal je overigens niet vinden in die tekst, dat is veel te specifiek. In de tekst staat zoiets "de overheid moet passend beveiligingsmaatregelen nemen in de volgende gevallen ... en de minister mag (laten) besluiten welke maatregelen precies passend zijn".

Daarbij kan de minister dan weer gebruik maken van het eerder opgerichte Forum Standaardisatie dat al heeft uitgezocht welke standaarden belangrijk en 'passend' zijn.
Is het de translate + voorbeelden van dit verhaal?

[Reactie gewijzigd door Emin3m op 10 september 2018 11:34]

Blij dat mijn hoofd domein hier tegen beschermd is, hoewel het geen Lets Encrypt draait kan deze via de aanval wel worden gebruikt tot het genereren van een certificaat dus het niet gebruiken van Lets Encrypt bied mij geen bescherming. Wel heb ik DNSSec geïmplementeerd en zou ik veilig moeten zijn. Als laatste stuk anti-spoofing wordt door alle browsers inclusief edge (en waarschijnlijk ook Internet Explorer) HTTPS afgedwongen (Hardcoded, HSTS Preload als een van de eerste en dus weid verspreid) het is dus zeer moeilijk mijn domein te spoofen ook al heb je deze nog nooit bezocht krijg je geen HTTP versie te zien.
moet de aanvaller een juist dns-antwoord zien op te stellen
Wat wordt hier precies met 'juist' bedoeld?
Zoals de echte dns-server het ook zou geven, of een voor een client geloofwaardig antwoord met de vervalste informatie (en dus feitelijk onjuist)?
<heb het netjes aan de redactie gemeld>

[Reactie gewijzigd door ronzelver op 10 september 2018 12:51]

Je kan gewoon in het forum je feedback kwijt: Geachte Redactie
Of je reageert hier: Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 44

Deze reacties hier hebben totaal geen meerwaarde :/
Commentaar op de redactie kan op GoT onder Geachte Redactie. De Feedback knop onder de auteur verwijst hier ook naar.

Omdat het artikel bijgesteld kan worden zonder versiegeschiedenis, is de discussie hier een beetje loos. Nu lijkt het of je loze kritiek hebt.
Maar JUIST omdat er bijgesteld kan worden zonder versiegeschiedenis is de discussie goed ipv het te verbergen in een topic waar niemand naar kijkt en zo er ook niet achter komt dat de kwaliteit vaak ver te zoeken is als het aan de redacteuren van de site zelf ligt. Je mag van een professionele/betaalde site wel verwachten dat de kwaliteit redelijk tot normaal is.
"De sites schrijven dat een aanvaller met methode in staat is"
"Vervolgens is het bijvoorbeeld mogelijk een kwaadaardige nepsite in het leven geroepen"

Het is toch belachelijk dat je voor dergelijke flut artikelen een forum reactie moet aanmaken.

[Reactie gewijzigd door ouweklimgeit op 10 september 2018 11:43]

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Games

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True