Xs4all ondersteund op de helft van de namesevers DNSSEC en ik kan als gebruiker geen vaste nameservers instellen door de load balancers.

Al een tijd hierover gediscussieerd met hun maar het schijnt absoluut ge prioriteit te hebben.

Dank voor jouw column! Inderdaad kan DANE (DNS-based Authentication of Named Entities) een goede bijdrage leveren aan betere beveiliging. Ook in Duitsland zijn hier veel verder mee (zie bijv. http://www.heise.de/thema/DANE).

Ik heb wel een paar opmerkingen: "Onmogelijk" is een groot woord. Zodra abnamro.nl (voorbeeld) haar certificaat vernieuwt moet die wijziging natuurlijk ook op de een of andere wijze in DNS worden doorgevoerd. Ik heb geen idee wat daarbij komt kijken, maar ik kan mij ook niet voorstellen dat daar niets mis bij zou kunnen gaan. Ik kan mij ook andere problemen voorstellen (waar mogelijk al goede oplossingen voor bedacht zijn): als je t.g.v. een Diginotar-achtig incident snel certificaten moet vervangen, zou het (door caching niet altijd even snel te wijzigen) DNS systeem wel eens een blok aan je been kunnen zijn. Maar toegegeven, hier heb ik mij nog niet in verdiept.

Maar dat wil niet zeggen dat XS4All klanten daar ook automatisch van profiteren; op bijv. een Windows 7 PC verschijnen er geen waarschuwingen als DNS antwoorden niet via xs4all worden aangeleverd. Er bestaan wel initiatieven om dit aan te pakken (zie bijv. https://www.nlnetlabs.nl/projects/dnssec-trigger/, bron: https://www.security.nl/posting/393515/Dnssec-Trigger), maar ik zie eindgebruikers resolvers als Unbound en software met de status "experimental" nog niet zo snel installeren.

Er moet dus nog veel gebeuren!

Gelukkig zijn er ook andere initatieven, zoals en certificate-pinning; bijvoorbeeld Microsoft EMET ondersteunt dit sinds versie 4.0 en Firefox sinds versie 32. Hoewel HSTS niet helpt tegen onterecht uitgegeven certificaten, helpt het wel voorkomen dat je naar een nepsite gestuurd wordt die van http gebruik maakt.

Hier een test om te controleren of jij (jouw ISP) al (voor je) valideert: https://dnssectest.sidnlabs.nl/ .

Overigens doet Google DNS wel DNSSEC-validatie. Maar dan gebruik je wel weer google. Laat in ieder geval zien dat het geen onoverkomelijke drempel is om validatie aan te zetten.

"Maar dat je voorloper kunt zijn laat bijvoorbeeld Zuid-Afrika zien met 33%. Nederland zit op ongeveer 5%."

Op de genoemde link (apnic.net) zijn overigens landen te vinden met veel hogere percentages, zoals bijv. Zweden (65.07%), Estland (67.54%) en ook wat kleinere landen met nog grotere ondersteuning, zoals bijv. Andorra (85.46%) en het mij onbekende "Saint Pierre and Miquelon" (96.28%)

Je weet wel, jeugdzorg, helden van het tegen rechters liegen, ouders zwartmaken, kinderen met grof geweld uit de vertrouwde omgeving slepen, het altijd beter weten en vooral nooit toegeven zelf wel eens fout te zitten. Dat mag zelfs niemand weten want "privacy van de medewerker", ook al zijn die uitvoerders van een publieke taak.

En dan heeft de beste man het over pielen in de marge aan de beveiliging van bankrekeningen. Hoezo maakt het hoofd van het digitale jeugdzorgdossier (zoals we ook al het EPD en het EKD en zo verder kennen) zich hier druk over? Heeft'ie niets beters te doen?

Er zijn wel betere dingen te bedenken ook dan de arme drommels van de volksvertegenwoordiging met een hoop techniese afkortingen om de oren te slaan, dat snappen ze bij voorbaat al niet. Is ook hun taak niet. Beleidsmakers moeten beleid maken, en daarom moeten ze snappen wat er belangrijk is op het niveau van beleid maken. (Niet dat de huidige generatie dat wel weet, maar genoeg afgedwaald.)

Die insteek over privacy is leuk, maar op beleidsniveau moeten we eerst eens wat fundering vormen. Als je daar serieus in wil zijn dan moet je het ook serieus doen: Anonieme bankrekeningen, of dan tenminste (bewijsbaar) anonieme betalingen. Laat daar de politiek maar eens over nadenken.

Hoe we daarna de techniek oplossen, ach. Begin eens met PKI op de schop te doen. Die twee hierarchieen van DNS(sec) en PKI overelkaar willen leggen zonder enige onderlinge verbinding was natuurlijk niet slim, maar om dan dat met een snel redmiddel (DANE) weer aanelkaar te plakken blijft behelpen. Duck tape als wondermiddel heeft ook zo z'n beperkingen, weet je.

Tja, de telecom infra in Afrika is anders dan in een economie zoals in het dichtbevolkde NL.
Met 3 ISP's waarvan 1 valideert heb je snel een relatief hoog getal. Absoluut verwacht ik die dat 5% van NL groter dan de hele 100% van ZA.
Daarintegen; .za is niet signed, dus een nationale 33% blijft knap.
En andersom: .nl is koploper in DNSSEC in ccTLD's, doch, procentueel (in registraties) gezien nog bizar laag.

Met autosigning in PowerDSN, Bind en Knot begint DNSSEC nu pas af te raken. En banken zijn extreem conservatief.

DANE gaat niet falen om gebrek aan DNSSEC, maar om browser-vendors die niet "willen" implementeren, omdat ze daartoe betaald worden door een anders ten dode opgeschreven industie.

Maar... banken als ING willen helemaal niet veilig zijn. Zo kunnen ze verliezen declareren bij hun verzekeraar Nationale Nederlanden; hetgeen de ING zelf is.

PKI is een verzamelterm. Ik denk dat je X.509 bedoelt.

Prima initiatief om dit aan de kaak te stellen. Vooruitkijken (voorkomen van toekomstig grootschalig misbruik) vind ik echter niet iets dat aan politici gevraagd moet worden. Maar als bijvoorbeeld 'iedereen' ondersteuning van DNSSEC aan zijn provider vraagt, moet dat resultaat boeken. Ik ga het bij Ziggo aankaarten en zal het antwoord hier publiceren.

Een andere speler met veel macht zijn de banken. Die willen zo graag vellig bankieren ondersteunen in het belang van hun klanten. Wel laat zij maar aankondigen dat over x maanden bankieren via DNSSEC verplicht wordt. Zouden providers dan wel willen overstappen?

Voor mij blijft wel de vraag wat het risico nu en vooral in de toekomst is. Wat voor toegang en apparatuur moet de georganiseerde criminaliteit krijgen/hebben om de zwakheid van DNS te kunnen misbruiken? En hoe staat het met mobiel bankieren?

Zucht... X509 records (certificaten) zijn onveilig, dus we gaan certificaten gebruiken om ze te koppelen aan een DNS server om ze veilig te maken...
Dat is als f7cking for virginity, dropping bombs for peace enz.

DNS servers zijn al niet veilig, je hebt geen controle over welke DNS server de client gebruikt (je hoopt maar dat ze die van de ISP gebruiken die DANE/DNSSec geimplementeerd heeft (en er zijn ook zoveel mensen die DNS begrijpen, zeker bij ISP's (NOT dus).
Backwards compatibiliteit is ingebakken (dus ook certificaten met MD5 (uit 1991, dat is het stenen tijdperk in ICT).
Verder worden alle certificaten met RSA versleuteld, je weet wel, het bedrijf wat miljoenen kreeg van de NSA om hun software 'beter' te maken voor de NSA.
Of misschien ECDSA, maarja, Sony weet al dat dit net zo veilig is.

Verder is DNSSEC een behoorlijke belasting op de DNS servers die op dit moment al vaak overbelast zijn bij ISP's. (degene die ze nog niet achter dikke loadbalancers hebben hangen (die ook behoorlijk lek zijn als ze in failover mode hangen).

Nee.. goed bezig...

Regelmatig zuchtende mensen, die precies weten wat er fout is lijkt het, zie ik zelden met een oplossing komen. En dat MD5 ondersteund wordt is goed om te weten (met dank), maar mij SP is toch niet verplicht dat te gebruiken?
Een lijst met zaken die een SP zou moeten implementeren om de tekortkomingen tegen te gaan, zou zeer welkom zijn!

DNSSEC en DANE zijn slechts een bouwsteen in een veiligheidsketen. Ze gaan niet al je problemen oplossen, maar scheppen daarvoor wel betere randvoorwaarden.

Ik (1444 zucht)wil wel helpen maar daar moet voor betaald worden.
Het is al weer 2 jaar geleden dat een ISP uit Nederland mijn hulp ingeroepen heeft. En dat was ook wel nodig ook. Helaas dat het financieel niet lukte om de meest basic beveiliging op orde te krijgen. Laat staan dat core-hardware nog in support zat. En dat voor een ISP in de top 5 vn NL. Beheerders die tftp niet begrijpen (en dus meteen verklaren waarom alle hardware draaide op de firmware waarmee het geleverd was. Die mensen moeten straks dnssec implementeren? Ja, externen huren ze wel in soms maar die mogen dan standaard beheer doen zodat de vaste mensen kennis krijgen van de nieuwr dingen. Faal is echter dat de vaste mensen geen ervaring hebben en maar wat doen en als dat faalt naar chefbeheerder google kijken.

Nouja. In ieder geval weer werk als de boel opgekocht wordt.

Voorlopig gebruikt security.nl zelf geen dnssec volgens mijn Chrome met extra plugin en die de basis DNS servers gebruikt via mijn SBS server

@ Vandaag, 16:11 Anoniem
Wat je hier (gratis) krijgt is weerwoord. En als die vorm van kwaliteitszorg niet op de zaak aanwezig is (ook wel "review" genoemd) is dat zeer waardevol en een must. Acquisitie lukt volgens mij zeker niet als je anoniem reageert. Opmerkingen zoals van 14:44 anoniem: 'het bedrijf wat miljoenen kreeg van de NSA om hun software 'beter' te maken voor de NSA', zijn amateuristisch volgens mij en zetten voor mij vraagtekens bij de andere beweringen.

Ik zou zeggen: noem 3 bouwsteen-punten die een SP zou moeten maken, zoals '15:59 Anoniem' aangeeft: 'scheppen daarvoor wel betere randvoorwaarden'. Helaas ben ik geen specialist op dit gebied. Wel weet ik dat als iemand zou zeggen dat er veel met wachtwoorden (vgl DNSSec) 'fout zit', dat nog geen reden is om het gebruik van wachtwoorden (DNSSec ) te verbeteren, laat staan wachtwoorden (DNSSec ) dan dan maar niet te gebruiken.

Er is altijd wel iets beters te doen, i.p.v. dat je dit tikte kon je ook een bejaarde helpen, wilt niet zeggen dat iemand iets niet kan aankaarten.

Op het niveau van beleid maken? Beleid maken voor een onderwerp kan alleen wanneer men er veel vanaf weet. In dit geval horen daar ook technische termen en onderwerpen bij. Ben je als beleidsmaker te lui of niet slim genoeg om deze technische termen en onderwerpen te begrijpen, dan is het hoog tijd om een ander onderwerp te zoeken of te vertrekken.

Ik hoop van harte dat je geen beleidsmaker bent, want allemachtig.....

Veel reacties en dat is leuk. Even wat feedback:

Enkelen zeggen:
- DNS is niet veilig. Inderdaad, dat DNS niet veilig is staat natuurlijk vast, het wordt dan ook gebruikt als middel in DDOS aanvallen en om mensen naar vervalste websites te krijgen.

- Certificaten zouden niet veilig zijn: ja dat is nu net het verhaal achter deze column: daar moeten we dus iets aan doen. Dat bepaalde certificaten verouderd zijn en met MD5: daar gebeurd nu bijvoorbeeld in de browsers iets aan: die zullen niet meer vertrouwd worden. Goede zaak lijkt me

Dit soort zaken zijn geen argumenten IMHO om dus maar niks te doen.

- Het argument dat DNS niet veilig is omdat je een niet beveiligde dns-server kunt kiezen. Ik vind dat vergezocht,. In praktijk gebruikt 99,9% de dns-server die hij/zij via DHCP van zijn provider krijgt. Die moet dus veilig zijn.


- Het argument dat politici niks snappen en dat je ze hier mee niet lastig moet vallen. Dat vind ik een erg negatief argument. Jazeker moeten we dat wel. Wie gaat anders tweede kamerleden uitleggen dat UPC een schop onder zijn h*l moet krijgen.

Precies waarom er politieke aandacht nodig is: de ICT sector zelf lost dit niet op.

tja waarom loopt nederland achter?

Omdat al die dnspanels van hostingpartijen gewoon geen TLSA record aanbieden. Ik zou graag met DANE willen spelen maar ik heb geen zin om speciaal daarvoor 2 nameservers op te gaan zetten. (of het moet projectmatig gebeuren, betaald).

Ik denk dat het daar moet beginnen, als dergelijke partijen TLSA records toevoegen in hun dnspanel kunnen nerds zoals ik ermee spelen en wordt het vanzelf wel uitgerold.

Toevallig dat ik gisteren nog aan een van de grotere hostingpartijen vroeg of ze TLSA wilden toevoegen als optie maar ik kreeg als antwoord dat de standaard niet definitief is en er voorlopig niets op de planning staat.

Je kan het zo zeggen, maar ook jij klinkt daarmee als iemand die wel de klok heeft horen luiden maar niet weet waar de klepel hangt. Laat ik het dus even anders zeggen: Ik denk niet --zoals hiertoe wel wordt opgeroepen-- dat de politiek zich nu met deze details bezig moet houden; er moeten eerst over andere, minder kleine details, en meer beleidsmatige details ook, beslist worden.

Want lange termijn heb ik niets aan superveilige transportkanalen die nog steeds tot gevolg hebben dat ik bij elke stap wordt gevolgd door hordes ambtenaren en quasi-ambtenaren en ingehuurde externen bij op afstandgezette bedrijfjes en weet ik het wie nog meer, die ik allemaal opsteltiaans maar gewoon moet vertrouwen.

Ik denk ook niet dat als je er "veel weten" bij gaat halen, de politiek veel te onderwijzen zal zijn en er ook niet veel verhelderends uit deze hoek gaat komen, niet vanuit zijn functie en niet vanuit zijn organisatie. Laat ze daar eerst zelf de boel op orde krijgen. Iets waar ik vanuit zowel organisatiehistorie als vanuit de beleidshistorie niet erg in geloof. Maar dan had ik dus veeleer verwacht dat'ie privacyproblematiek in de electronische dossiervorming zou aankaarten. Je hoort dan vooral over het EPD, maar als je mij wil overtuigen dat dit electroniese dossier toch echt anders is, moet je goed beslagen ten ijs komen. Maar hee, als jij het beter weet, doe je ding en laat zien.


Het gaat niet alleen om de certificaten. De hele cottage industrie eromheen is niet meer dan wat in technische termen "snake oil" heet te zijn. Iedere willekeurige dodo kan nog steeds een certificaat voor andermans website registreren. Wil'ie direct een MITM doen dan heeft'ie toegang tot bijvoorbeeld het desbetreffende web based-dns management-paneel nodig en moet'ie wel twee dingen aanpassen, niet één.

Maar voor de "bijna dezelfde naam"-taktiek hoeft'ie geen toegang tot andermans panelen te krijgen maar heeft'ie een provider nodig die ook de extra DNS records toe kan voegen. Het is een niet heel moeilijke extra stap, die hooguit wat extra werk betekent. Voor je het weet springen er in het zwarte circuit dienstverleners op die dit industrieel doen.

Het is dus dweilen met de kraan open.

Mijn kritiek was heel duidelijk dat ik me ernstig afvraag waarom jij politici met precies dit wil lastigvallen. Het is een specifieke techniek die volgende week anders kan zijn. Leg'm vast in de wet en over twee weken lopen we achter en hebben we weer politici nodig om iets ander in de wet vast te leggen. En over vijf weken weer. En zo verder.

We hebben dus een andere insteek nodig, iets wat naar verwachting iets langer de tand des tijds zal doorstaan. En ook daar zijn nog genoeg leuke balletjes op te gooien.


Ik denk niet dat de ivoren kaasstolp om het even welke ISP hiervoor schoppen waar dan ook moet verkopen. Ik denk wel dat er daar nog genoeg te doen is, bijvoorbeeld met de privacy in de in overheidsnaam gevoerde dossiers, of zelfs de in de bankiersector gevoerde dossiers.

Van iemand die vanuit jouw organisatie spreekt een beetje een pot-ketel verhaal. Ook omdat de overheid als geheel zelf steeds minder oplost maar wel meer kost. Ik zie dus niet waarom dat met alweer een extra en essentieel arbitraire verplichting aan deze of gene marktpartij ineens beter zal gaan. Het moet namelijk uiteindelijk wel gedaan en betaald worden, een gebeuren waar de ambtenarij veel te vaak maar al te makkelijk vanuitgaat. Maar laat ik niet al te flauw doen. Laat ik realistisch doen.

Weten we al wat "de gebruiker" moet doen als er zo'n vervelend popupje meldt dat er "iets" niet goed is met de Deen (wat? buitenlanders? honden?) in de deejenes (de wat nu weer?) die je óf kan wegklikken --en dan doet bankieren het niet, potverwaarzijnmijndubbeltjes ik heb nog meer te doen-- óf waar je door op maar flink veel knoppen met irritante wachttijden je toch bij je geld kan. Wat gaat er gebeuren denk je?

De link tussen doorklikken en geld kwijtraken aan oplichters zal pas veel later naarbovenkomen, en dat is dan nog meer de schuld van de eindgebruiker want we hebben toch al die mooie afkortingen die vanalles beter maken, en dus wordt de schade niet vergoed.

Vinden de banken geweldig, dus wend je vooral tot hen als je lobbymedestanders nodig hebt. Wat mij betreft echter is het niet meer dan leuk dagdromen over technies met de tijd mee moeten en andere drogredenen, maar uiteindelijk wordt de burger er niet beter van. En dat terwijl er nog best genoeg te doen is.

Hans-Cees, sowieso geef ik je gelijk dat er best wel iets van aanpak geforceerd mag worden.
Als we domme cookie wetgeving Europa in kunnen knallen; dan lijkt dit mij een belangrijker agenda puntje.

Dus i.p.v. phising slachteroffer ben je nu dagelijke gem. 2.5x down, omdat je MITM ben in een DNS amplification attack.
DJB heeft dat al meer dan een decenium geleden voorspeld als voornaamste uitkomst.
Een "klein" probleem is opgelost, een GROOT probleem is er voor in de plaats gekomen.

Het aantal browsers waar DANE standaart in ondersteund wordt is exact 0 (zegge: "nul").
En echt; het huidige certificaten conglomeraat laat zich niet zomaar wegvagen.
Andersom: waarom gaat er dan geen enkele browser-maker de concurrentie daarmee aan?

Dat is deel A van het verhaal. En B is dat domeinen dan wel ge'signed moeten zijn. Dat wordt een harig onderwerp.
Hoeveel van ALLE banken in Zwitserland gebruiken DNSSEC?
Ondanks dat .ch bij de eerste 6 DNSSEC enable'de ccTLD's zat, was dat 1.5 jaar geleden exact 0 (zegge: "nul").
En in heel Portugal (.pt) zijn er minder dan 1000 ge'signde domeinen.

...is onderschatting en generaliserend. Er zitten in de kamers best wel wat knappe koppen die kunnen communiceren op het niveau van hun soortgenoten.

ICT-sector klinkt commercieel. Ik denk dat meteen aan het ECP clubje. En politiek klinkt verheven boven het electoraat. Geen van beide gaat dat beter oplossen dan bijv. zelfregulerende prijzen in mobiele telefonie. Politici lopen vrijwel altijd achter de feiten aan, zeker in ICT.
Ikzelf verwacht de revolutie meer van open-source hippies. Zo doet Postfix bijv. ook DANE.
Als we dat in FTP, SIP, en weetiknietwat gaan zien, dan komt het vanzelf wel een keer door.

Hosters hebben maar één belang, bandbreedte verkopen en ijzer vullen.
en dat dat doen ze ook voor van illegale / twijfelachtige sites, ze hebben helemaal geen belang bij maatregelen die geld kosten en ook nog eens minder business oplevert.

alleen dwingen zou kunnen helpen

XS4ALL werkt met een mix van validerende (Unbound) en niet-validerende resolvers (PowerDNS, die kan dit nog niet).

niet-validerend: 194.109.6.66 / 2001:888:0:6::66
validerend: 194.109.9.99 / 2001:888:0:9::99

Je hebt als eindgebruiker niet standaard in de hand tegen welke resolver je praat.

PS: ik werk niet voor XS4ALL, dus ken niet alle technische ins-and-outs, maar dit is zoals het er vanaf een XS4ALL-shellaccount uit ziet (zie bijvoorbeeld de /etc/resolv.conf aldaar).

Overigens weet ik dat XS4ALL plannen heeft om alles naar validatie te tillen.

Verder schreef je "Overigens mijn modem kan alleen met DNSv4 en DNSv6 omgaan". Ik zou zeggen: "niets meer aan doen", maar mogelijk begrijp ik je verkeerd. Misschien bedoelde je dat jouw modem nog geen DNSSEC-records snapt. Dat zou kunnen inderdaad. In dat geval zou je dus je modem niet moeten gebruiken als DNS-forwarder (dat is wat veel modems doen; via DHCP krijg je niet allen een IP-adres van ze, maar spelen ze ook DNS-forwarder voor je).

DANE kan een goede basis vormen voor een veiliger internet.

Het is echter een misvatting dat ISPs de validatie moeten doen. DANE is het meest effectief als de applicatie (browser, app) zelf de DNS-resolving en DANE validatie uitvoert. Het helpt als de host een DNS-resolver van een ISP kan gebruiken als cache. De DSN-servers van de ISP hoeven geen validaties uit te voeren.

Je hoeft dus niet te wachten op de ISP's.

DANE heeft nog een voordeel, het is backwards compatible, je kunt het dus al toepassen, oude clients die het niet toepassen hebben er geen baat bij maar ook geen last van.

Het nadeel is dat je een extra beheersstap hebt. Maar dat kun je heel beperkt houden. Met DANE kun je aangeven wie de CA is voor een site. Zolang je niet van CA wisselt hoef je het maar 1 keer in te stellen.

Blijft het probleem dat de meeste hostingproviders nog geen TLSA-records kunt configureren.

Zie hier mijn ideeen om met DNSSEC en DANE het phishingprobleem op te lossen:

http://eccentric-authentication.nl/Icann-talk-phishing-protection-4.pdf

Guido.

Maar ehm... "mijn ideeen"?
Volgens mij slechts een visualisatie van DANE, niet?

Sinds 2008 heeft deze ISP modems uitgegeven die kunnen omgaan met DNSSEC. De aanpassing zal dus alleen aan de provider kant moeten komen.

Pierre.

Relevant: http://dnssec.nl/cases/dnssec-inventarisatie-grote-verschillen-tussen-sectoren-1.html

Dat is dus niet helemaal waar:

https://www.dnssec-tools.org/wiki/index.php/Bloodhound

Ik weet precies waar ik het over heb. Ik heb meerdere malen meegemaakt dat beleidsmakers (ook in de hogere regionen), die soms al jaren met een onderwerp bezig zijn, nog steeds te beroerd zijn om de basis te begrijpen.

Men hoeft niet perse een beta studie te hebben gedaan voor technische basisprincipes. Ik ben (alfa/gamma's) beleidsmakers tegen gekomen die de basis principes (in dit geval digitale communicatie) eigen maakte, terwijl anderen, aan dezelfde tafel en functie, het gewoon niet lukte. Lukt het je niet om de basis principes te begrijpen, dan moet je maar extra hard werken om het wel te begrijpen, van onderwerp veranderen of vertrekken.

Met beleid op hoog niveau alleen zal men er nooit komen, want uiteindelijk moet het ook resulteren in daadwerkelijk uitvoerbaar beleid. Men noemt het graag op hoog niveau, omdat het tegenwoordig als excuus wordt gebruikt om je maar niet te hoeven inlezen op een onderwerp.

Mocht voor DNSSEC toevallig beleid worden gemaakt, zal men toch echt moeten weten, hoe en waarom het nodig is. Zonder inlezen/begrijpen van de basis werking van DNS(SEC) en het gebruik ervan (zowel positieve als negatieve punten) kan nooit een goed beleid opleveren.

Het inhuren van vele externe partijen is een tendens die de laatste jaren steeds erger wordt, maar vaak gebruikt wordt om, wanneer het fout gaat, de externe partij de schuld te geven. Gewoon luiheid of incompetentie is ook een reden.

Over het nieuwe EPD kan ik kort zijn, dat is het gevolg van onkunde in combinatie met belangenverstrengeling van verzekeringsmaatschappijen.

De eerste 4 woorden van die pagina zeggen:
This is a patch

Mijn stelling blijft dus:
Het aantal browsers waar DANE standaart in ondersteund wordt is exact 0 (zegge: "nul").

Desondanks; intressant! Dank je voor het posten.
Ikzelf gebruik de meer bekender https://www.dnssec-validator.cz/
Die geeft slechts informatie, en blocked (nog) niks, dus echt beschermen doet het niet.


Uberhaubt; een organisatie betalen om die vervolgens te laten zeggen dat je betrouwbaar bent... als je dat IRL gebeurt; vertrouw je dat dan?
Self-signed certificaten met een TLSA lijkt mij een stuk minder klandestien.

Mijn excuss; als ik voorbij de misleidende introductie kijk, zie ik dat je toch gelijk had:
"Bloodhound is a re-branded version of the Mozilla Firefox browser that supports local DNSSEC validation and the DANE protocol."

Helaas vind ik geen .exe of .dmg, maargoed, het is een begin.

Mijn ideeen gaan verder dan alleen laten zien hoe DANE werkt.

Met 'standaard' DANE-gebruik, zoals voorzien door de auteur van het artikel biedt DANE bescherming tegen Man-in-the-Middle aanvallen. Een crimineel kan geen certficaten meer aanmaken voor abnamro.nl. Maar nog wel voor phishingsites zoals abn-amro-verzekeringen.nl en de layout van Abn-Amro kopieren en zo proberen om mensen verleiden op die site in te loggen en hun account te stelen.

Ik bouw voort op DANE en laat zien hoe je door het gebruik van DNSSEC, DANE en client certificaten dat phisingprobleem kunt oplossen. Een crimineel kan dan wel een gebruiker verwarren maar niet diens computer. Voor de computer zijn dat twee verschillende sites met twee verschillende identiteiten. De computer van het slachtoffer zal niet met de credentials van de bank inloggen bij de site van de crimineel. De crimineel kan niet de 'digitale identiteit' van de bank overnemen. De crimineel beschikt niet over de private key van de bank's eigen CA waarmee alle certificaten gesigneerd zijn. En bij een goede installatie kan de private key van die CA op een USB-stick in de kluis. Die is niet online nodig en kan dus ook niet door een server-hack bemachtigd worden.

Zie: http://eccentric-authentication.org

Guido. (guido at witmond.nl)

Gewoon bij downloads:

http://www.dnssec-tools.org/download/bloodhound-26.0.1.en-US.mac64.dmg

Hans-Cees,

Waarom wil je DANE aanprijzen als 'oplossing' voor bankphishing ?

Is dat alleen maar argumentatie, en gebruik je bankieren als "voorbeeld" omdat je TLS en het certificaten framework wilt verbeteren ?
Of denk je werkelijk dat de phishing zoals die nu speelt uitgevoerd wordt op een manier waar DANE tegen helpt ?

Want wat ik zie aan bankier phishing zijn vergelijkbare domeinen (of niet eens), social engineering in de tekst van de phish mail (en zelfs telefonisch) , en trojaned eindgebruiker PCs.
Allemaal vectoren waar DANE niet tegen helpt.

Ik zou het erg onethisch vinden wanneer een techneut/adviseur liegt dat een bepaald herkenbaar probleem opgelost wordt door een techniek in te voeren, wanneer die techniek voor dat probleem van erg beperkt nut is.
Op zo'n manier ga ik nog begrip krijgen wanneer politici en andere beslissers niet erg luisteren naar 'advies van deskundigen'.

Mocht je werkelijk denken dat bankphishing vooral berust op het onterecht verkrijgen van certificaten voor bankier websites in combinatie met DNS spoofing zou ik zeggen, ga wat huiswerk doen en analyseer je spamfolder.

Er zijn zeker gebieden waar DANE echt verbetering zou geven, maar zoals bankphishing gedaan wordt help DANE / DNSSEC bitter weinig.

Hij argumenteert dat DANE i.c.m. client certificaten een oplossing zijn. Nu is dat technisch gesproken waar, immers zonder een geldig client certificaat kun je dan niet bankieren. En het SSL certificaat van de bank kan gecontroleerd worden m.b.v. DANE.

Echter, ik zie dit alleen werken in apps waarbij vanuit de app verbinding gemaakt wordt met de bank server. Dit voorkomt namelijk phishing; het is niet mogelijk om een verkeerde URI in te geven omdat dit door de app wordt geregeld en een MitM is niet mogelijk omdat met behulp van DNSSEC en DANE kan worden geverifieerd dat er daadwerkelijk met de bank gecommuniceerd wordt.

Voor in de browser is het denk ik geen oplossing. Alleen al omdat het gebruik van X.509 client certificaten dermate gebruikersonvriendelijk is dat het voor het gros van de gebruikers al snel te ingewikkeld wordt. Om nog maar niet te spreken van het feit dat het best practice is om client certificaten in de browser te genereren zodat de private sleutel het systeem van de gebruiker niet verlaat. IE en Chrome gebruiken onder Windows een gezamelijke Windows certificaat store, Firefox heeft een eigen versie. Om het aangemaakte certificaat met meerdere browsers te gebruiken, moet je deze dus zien te exporteren tussen de verschillende certificaat stores. En wat als je ook de browser op je mobiele telefoon of tablet wilt gebruiken? Voor de gewone gebruiker veel te moeilijk. Als je de gebruiker meerdere X.509 client certificaten laat aanmaken, dan kan de phisher dat ook doen namens de gebruiker omdat per definitie gebruik gemaakt moet worden van een niet met X.509 client certificaten beveiligde verbinding om deze client certificaten aan te maken. Waar de phisher dus tussen kan zitten.

Ik ben zelf groot fan van X.509 client certificaten, maar denk dat deze alleen geschikt zijn voor een (kleine en) gecontroleerde hoeveelheid gebruikers. En, tenzij dit in een bedrijfsomgeving standaard uitgerold kan worden, het liefst ook nog gevorderde gebruikers met enige technische kennis die snappen hoe het werkt.

DANE gaat niet over client certificaten, en Hans-Cees heeft het daar ook niet over.
Bij DANE wordt in DNS, en beveiligd via DNSSEC aangeven welk server certificaat echt bij een site hoort.

Zodat een server certificaat getekend door een compromised root authority die toevallig wel in de browser lijst zit toch niet geaccepteerd wordt.
En die aanvalsvector komt voor internet bankieren gewoon niet of nauwelijks voor.


Ze _kunnen_ ook grootschalig gebruikt worden , op een smartcard in een bedrijfsomgeving voor gebruikers login en authenticatie.
(samen met een passphrase/pin ).

Zomaar een idee in de lucht gooien is wat politici doen... Ze denken een probleem te zien, kijken dan 2 dimensionaal ernaar en kiezen dan het dichtsbijzijnde makkelijke antwoord. Zonder ook maar na te denken over de consequenties of eventuele acties van de omgeving waar je jouw 'antwoord' op los laat.

Laatste problemen met Ambtenaren die zo dachten zijn o.a. bijtellingstarief aanpassing naar 25%, bijtellingstarief 0%, 7%, 14% 20% en 25%, oldtimerregeling, wegenbelastingaanpassing. cookie-wetgeving, downloadverbod,thuiskopieheffing enz enz. Allemaal acties voor maatschappelijke problemen die #1 niet zo hoog op de agenda stonden (cq zouden moeten staan) en allemaal niet goed doordacht of alleen op papier leuk.

Ieder weldenkend mens kon bedenken dat als je 14 jaar lang 25% bijtelling moet betalen voor een auto en deze auto dan virtueel in die 14 jaar (ja, niet iedereen heeft een zakelijke LEASEauto maar er zijn ook bedrijven die zelf een auto kopen) dan via de belasting al die auto al 5 keer betaald hebt. Als je ZZP-er bent, is het verd. ook nog eens je eigen geld waar je belasting over moet betalen. En als je een grijs kenteken koopt moet je zelfs betalen voor BPM (wat je niet hebt op een grijs kenteken) en voor BTW (die je afdraagt als ondernemer) maar waar je dus wel 25% belasting over moet betalen.

Goh, en er is sinds de invoering een instorting van de 'gewone' automarkt... Nee, dat had echt niemand kunnen voorspellen. Goedlopende autobedrijven die niet de beschikking hadden over een =< 14% bijtelling auto gingen op de fles. Dankzij de overheid en hun incompetentie.
Hebben we het nog niet gehad over benzinepompen in de grensgebieden. Goh, beetje gegoochel met CBS cijfers die vals blijken te zijn en dan het vreemd vinden dat de bevolking de overheid niet meer serieus neemt. Goh, ook dat niet te verwachten.
Of de cookie wetgeving. Zelfs de overheid zelf snapte het niet. En dan de cookie wall websites. Je moet slikken of je komt de website niet op. En ja, voor een principe hebben mensen niet veel over als ze langer dan 2 seconden moeten wachten op een nieuwspagina. Dus de hele cookie wetgeving heeft miljoenen gekost maar levert alleen maar frustratie en tijdverlies op waardoor er nu nog meer stroom verbruikt wordt en het nog ecologisch ontverantwoord is ook. Maar ook hier hadden ambtenaren dit niet verwacht... Ja, wat verwacht je van OV-konijnen die nog in stapeltjes maandag-dinsdag-donderdag denken. (woensdag is voor de kinderen en vrijdag deden ze toch al niets dan facebook testetn.

Maar die overheid met een 10 als rapport cijfer voor ICT projecten gaat nu effe concluderen dat DNS secure moet worden gemaakt met technologie die gemaakt lijkt voor/door de NSA... Nee, dit gaat mensen die naar www.ie-en-gee.nl gaan en daar hun spaarrekening dumpen helpen....

ZUCHT!

Mijn excuses, omdat in de post boven u (toevallig) over hetzelfde ging maar ook client-certificaten in de reactie werd genoemd, had ik per abuis aangenomen dat uw reactie daar op gericht was.

Hans-Cees wil DNSSEC en DANE gebruiken om DNS-spoofing en roque access points gemakkelijk te detecteren (eigenlijk alle MitM aanvallen):

Zoals hier in Nederland altijd is:

Er moeten eerst "doden" vallen voordat er actie ondernomen wordt...

Met andere woorden, er moet eerst een flinke hack plaats vinden met veel gestolen gegevens van burgers voordat de providers wakker worden...

Nog meer leuke discussies.

Het gaat mij erom dat de overheid er voor zorg zou moeten dragen dat er een een veilige internet infrastructuur voor burgers, consumenten en bedrijven is of komt. Zoals de overheid er ook voor moet zorgen dat stoplichten goed werken en eisen stelt aan de uitlaatgassen van auto's.

Een ministerie van ICT? Misschien wel? In ieder geval zou de overheid veilige ICT infrastructuur als kerntaak moeten adopteren. Dat betekent bijvoorbeeld vaststellen dat DNSSEC op dit moment een key verbetering is die er moet komen. Maar ik zie dat als een voorbeeld, maar wel een relevant voorbeeld op dit moment. Een ander voorbeeld is ipV6.

De overheid zou overstijgend vast moeten stellen wat er nodig is en met allerlei instrumenten de juiste richting op moeten sturen. Op dit moment is er geen politicus die "internet veiligheid" wil. Dat vind ik schokkend, gezien de hoeveelheid internet handel en geboefte.

En inderdaad DNSSEC is niet DE oplossing NU tegen fishing. Maar kan wel een hoeksteen zijn van toekomstige oplossingen tegen fishing.

Overheid is er niet voor ons en laten we AUB overheden trachten te mijden zich te bemoeien met technologie die juist de burger meer vrijheden bied.

Verder is de DNSSEC discussie een NON-DISCUSSIE.

Als eerste DNSSEC word door geen enkele MAINSTREAM OS ondersteund (van windows xp t/m 8, Apple OSX, IOS en Android).

Microsoft gaat er vanuit dat je NAMESERVER DNSSEC voor je gaat valideren.

Bovendien als er op een dag (over jaartje of 5?) meeste devices wel over een OS beschikken die default DNSSEC doen, hoe kan gebruiker zelfstandig vaststellen dat DNSSEC wel zijn werk doet?

Met andere woorden hoe kun je resolver van je OS vertrouwen?

Door DNSSEC (zoals CLOUD) te hypen schep je verwachtingen en daarmee maak je JUIST het Internet onveiliger omdat mensen denken dat het allemaal wel goed zou moeten zitten.

Bovendien als men toch al ergens op je computer, je verbinding, je ISP, de registrar, de website die je bezoekt de nameservers kunnen "beinvloeden" heb je een veel groter probleem dan DNSSEC kan oplossen.

Sterker nog, vertrouwen in DNSSEC is hetzelfde als blind vertrouwen op een virusscanner.... het maakt mensen juist onoplettend, terwijl mensen nu juist de zwakste factor zijn in het geheel.

Het is voor mij beangstigend dat er amper kritische geluiden te horen zijn over DNSSEC, kennelijk lopen er meer mensen met het label security officer/specialist rond, dan mensen die daadwerkelijk er verstand van hebben.

Om maar te zwijgen over wat er bij de overheid aan competente mensen op die gebied rondloopt.

Het enige wat ons allen veilig zal maken is product aansprakelijkheid voor software, OS leveranciers worden dan gedwongen om een degelijk product af te leveren. Software is laatste jaren steeds meer functie gericht en steeds minder door competente mensen geschreven, waardoor (o.a. security) patches normaalste zaak van de wereld is geworden.

Maar zolang onze overheid gaat lunchen en laat adviseren door o.a. directie van Microsoft zie ik dat er nooit van komen.

ps: Hans-Cees hoe denk jij dat DNSSEC hoeksteen tegen phising kan zijn? Denk je nu echt dat men een technologische oplossing kan verzinnen tegen stupide handelingen van mensen? Kennelijk heb je nooit gezien in wat voor phising emails sommige mensen trappen, want de meeste phising sites die wij bijna dagelijks voorbij zien komen, bevatten geen verwijzingen naar domeinnamen van legitieme instanties en ik heb nooit een phising site gezien met een SSL certificaat.
Bovendien alle phising sites die wij in de afgelopen 5 jaar voorbij hebben zien komen, staan op gehackte websites, ergens in een vage sub-sub directory.

Ik ben van mening dat juist pseudo-security specialisten die laatste tijd in de media hun mening uiten een groter gevaar is dan alles wat nog verzonnen kan en zal worden.

Als je niet dagelijks met je voeten in de modder staat en operationeel betrokken bent bij afhandelen van incidenten, ga dan geen onzin verkopen, want het gevaar is dat mensen je nog gaan geloven ook.

mvg,
G.M.

Ik wel :-)
(denk aan ABS in je auto). Maar dat terzijde.

Deze discussie gaat nogal veel kanten op.

Eigenlijk is het heel simpel:

- DNS is intrinsiek onveilig.

Dat is een feit. Niets doen is uiteindelijk geen optie.

- DNSSEC beschermt (bij juist gebruik) effectief tegen cache pollution. Ook dat is een feit. Nu misschien nog niet zo urgent, maar je kan maar beter klaar zijn voor de dag dat dit omslaat. Want, zoals je zelf aangeeft; de weg is lang. In de internet-infrastructuur is al veel gebeurd, maar op OS-niveau is nog het nodige werk te verzetten.

- DNSSEC is een nuttige beveiligingsbouwsteen, alle incompetente gebruikers en/of politici ten spijt. Met 'hypen' heeft dit niets van doen.

Hoe een gebruiker kan vaststellen of zijn DNS(SEC) werkt en of zijn resolver wel te vertrouwen is en dat er heus nog wel andere narigheid is waar we momenteel meer last van hebben in de praktijk, heeft helemaal niets met deze discussie te maken. Zo lust ik er namelijk nog wel een paar.

Hoi Hans Cees,

Wanneer wordt 'jeugdzorgnederland.nl' voorzien van DNSSEC?
(en waarom geeft https://wijz.jeugdzorgnederland.nl/ andere content dan http://wijz.jeugdzorgnederland.nl/ ?)

Vaag bericht, maar mogelijk toch ook een veeg teken:

https://www.virusbtn.com/blog/2014/09_12.xml
(en de bron: http://www.cert.org/blogs/certcc/post.cfm?EntryID=206 )

Over cache pollution in het wild.

DNSSEC grootschalig implementeren doet mij denken aan het verlangen dat ieder domein van SPF records voorzien zou zijn...
En de haalbaarheid ervan dus ook.

Lekker DNSSEC laten implementeren door prutsers van ISP's... die laten een groot gapend gat open staan en kan via de DNServer van de ISP nu echt goed geinjecteerd worden...

Internet = onveilig..

als je op internet veilige dingen wilt doen heb je een betonblok voor je hoofd.

Niemand zegt dat het makkelijk is, maar niets doen gaat dat probleem niet oplossen. Er is altijd hoop. DKIM/DMARC bijvoorbeeld, is wel redelijk goed gaan vliegen. Alle grote e-mail toko's ondersteunen dat (met succes).

DNSSEC is ook al redelijk grootschalig geïmplementeerd (vanaf de root-zone tot aan vele miljoenen domeinnamen). Aan de validatiekant hebben Google Public DNS en enkele andere grote partijen het ook aan staan.

Not all is lost.

Gewoon optimistisch blijven (en constructief), dan komen we er wel.

Er wordt hier veel gepraat over DNS. Maar weinig zinvol. Allereerst bestaat er geen DNSv4 en DNSv6. Het is gewoon DNS. En dat ondersteund IPv4 en IPv6. Er bestaat wel DHCPv4 en DHCPv6.

DNSSEC is relatief veilig als je wilt weten of diegene die jouw een authoratief antwoord geeft ook degene is die "eigenaar" is van de zone. Dit uitsluitend als het gehele traject (auth. DNS server, caching DNS server en client dit ondersteunen. Anders zal de client er niets om geven en de check niet uitvoeren.

Dus om dit volledig goed te laten werken moeten de auth DNS servers geen queries accepteren die niet gebuik maken van de DNSSEC flag. Dit houdt in dat iedereen die geen DNSSEC gebruikt, geen antwoord krijgt.

En hier is het grote probleem. Wie weet zeker dat ie de DNSSEC flag gebruikt? En dit ook in het gehele traject (resolving DNS servers) zo blijft? Daarnaast is de key van DNSSEC tijdsgevoelig. En als DNSSEC aanstaat en de key verlopen is, werkt het ook niet. Deze key staat op een zone. Iedere keer als de zone wijzigt, moet de key opnieuw gegenereerd worden. Zo niet, werkt het weer niet. etc. DNSSEC is redelijk complex in gebruik, dus automatiserin van het proces is een vereiste.

Ook zal het gebruik van DNSSEC de benodigde bandbreedte voor DNS doen exploderen, beslasting op firewalls wordt groter en het resolving proces duurt langer. Dus om nu even snel DNSSEC te implementeren omdat iemand zoiets ald DANE heeft uitgevonden.... DNS is al teveel in gebruik als een tool voor andere problemen (MS AD, SPF etc).

Dit soort ontwikkelingen hebben toekomst. Op basis van een veilige onder-laag, of infrastructuur worden weer slimme andere dingen mogelijk.

Veel mensen hierboven die bezwaar maken met allerlei redenen waarom iets niet gaat werken hebben ongelijk want denken onvoldoende in "enabler" theorie. Dns is een basis-laag (enabler) en onveiligheid valt lastig op een andere laag op te lossen. Natuurlijk lost veilig DNS niet alles op. Zoals riemen vast in de auto niet alles op lost.
Maar het is wel verdomd verstandig.

Alle verhalen dat het technish niet zou kunnen zijn complete apekool. Wanneer de grootste internet denktanks hierachter staan hebben ze daar heus wel over nagedacht.

Hier zijn wat correcties op hun plaats:

Authoritative name servers blijven gewoon queries accepteren van resolvers die geen DNSSEC ondersteunen, dus niet valideren. DNSSEC is dus zo ontworpen dat het backward compatible is, met oude software. Er komt dus wel degelijk een antwoord, alleen weet je niet zeker of dat klopt, omdat he het niet hebt kunnen valideren.

Voor een gemiddelde gebruiker speelt DNS(SEC) zich af onder de motorkap. Of hij praat met een validerende resolver, is lastig vast te stellen. Maar op https://dnssectest.sidnlabs.nl/ zie je het binnen seconden. Uiteraard gaat dit in de toekomst verbeteren, als DNSSEC gemeengoed wordt en ook browsers en andere applicaties gebruikers kunnen inlichten over onveilige situaties (vergelijk het maar met het wel of niet tonen van een SSL/TLS-slotje in een https-url)

De sleutels van DNSSEC zijn niet tijdsgevoelig. De digitale handtekening onder DNS-antwoorden is dat wel (de zogenaamde RRSIG). Dat is logisch, want je wilt niet dat ze oneindig lang geldig blijven. Denk aan een DNS-replay aanval, waarbij een kwaadwillende hacker oude en inmiddels niet meer actuele informatie kan blijven afspelen tegen een niets vermoedende gebruiker. Zou niet best zijn als de handtekening onder dat valse antwoord ook nog eens geldig zou zijn en dus de aanval niet opgemerkt zou kunnen worden. DNSKEY's verlopen dus niet, dit in tegenstelling tot de RRSIG's. In de praktijk worden ze wel regelmatig 'gerolled', dus vervangen. Bijvoorbeeld elke twee maanden voor zone-signing key's en elke 3-5 jaar voor (de moeilijkere) key-signing key's. Dit om het brute force kunnen kraken van de key (een voornamelijk theoretisch probleem, maar toch...) tegen te gaan.

Als een zone veranderd, moet deze opnieuw worden gesigneerd. Dat wil zeggen dat RRSIG's daar waar nodig worden ververst en NSEC/NSEC3 records daar waar nodig goed moeten worden gezet. Ook als een zone *niet* veranderd, moeten RRSIG's bij tijd en wijle (voordat ze verlopen) worden ververst. Het spreekt voor zich dat DNS-software dat tegenwoordig volautomatisch voor je doet allemaal.

Bandbreedte zal absoluut niet exploderen! Ik durf dat met droge ogen te zeggen, want ik werk voor een club die recht van spreken heeft, omdat we dit en tal van andere aspecten nauwgezet in de gaten houden. Ja, de DNS-antwoorden worden met DNSSEC groter, maar DNS verbruikt van zichzelf al niet zoveel bandbreedte en zelfs als je dat vertienvoudigd, is het nog steeds niet heel veel. Belasting op firewalls wordt ook niet noemenswaardig groter. Als dat wel zo zou zijn, hadden we dat namelijk al lang gemerkt. De rootzone en de .nl-zone zijn als sinds 2010 gesigned en BIND, een van de meest gebruikte resolvers, heeft al sinds jaar en dag de zogenaamde DO-bit gezet (wat zoveel wil zeggen als: 'geef me die grote DNSSEC-antwoorden'). Weliswaar valideerde BIND destijds nog niet (de laatste jaren uiteraard wel), maar die grote antwoorden krijgen we dus al jaren en hebben destijds (en tegenwoordig al helemaal niet meer) niet tot noemenswaardige firewall-problemen geleid.

Resolving duurt een fractie langer met validatie, maar dat is alleen de eerste keer he? Alle vervolg-queries worden gedurende de TTL vanuit de cache beantwoord en dat gaat nog steeds vliegensvlug.

DANE is uitgevonden, na DNSSEC overigens en bouwt voort op mogelijkheden die met DNSSEC ontstaan. Daarom vereist het DNSSEC Als DKIM vandaag zou worden uitgevonden, zou het ook DNSSEC vereisen - wel zo logisch.

Dus om even snel DNSSEC te implementeren? Waarom niet? Het protocol is volwassen, bewijst zich dagelijks in de praktijk, de software-tools zijn daar en een beetje dappere ICT-er met clue (ze bestaan nog, maar mogelijk werken ze voor je concurrent) deinst er niet voor terug.

Al iets veranderd?