image

Column: Veiligheid internetbetalingen ondergraven: providers ondersteunen geen DNSSEC

maandag 8 september 2014, 11:19 door Hans-Cees, 51 reacties

Sinds de Snowden-leaks weten we dat internetprivacy en veiligheid niet puur academisch gebazel zijn, maar een zeer praktisch probleem. Het grote aantal phishingmails gericht op betalingen, IBAN en dergelijke toont aan dat criminelen proberen de beveiliging tussen bank en burger te kraken. De beveiliging die betalingen via internet veilig maakt rust op twee pijlers: TLS/SSL-beveiliging tussen het device van de burger en de bank en ten tweede het cryptografisch "tekenen" van opdrachten met bijvoorbeeld tokens. Deze twee lagen zijn een mooi voorbeeld van defense in depth: wanneer de ene laag zwak zou blijken door een aanval zorgt de tweede laag ervoor dat een aanval niet onmiddellijk lukt.

TLS-laag onder vuur

De TLS-laag ligt op dit moment onder vuur. TLS is de encryptie van informatie tussen browser (of app) en websites. Het probleem ermee is dat er wereldwijd teveel uitgevers van certificaten zijn die door de browsers worden vertrouwd. Dat maakt het mogelijk valse certificaten te verkrijgen, zie bijvoorbeeld dit bericht: Een aanvaller die één van de 200 certificaat autoriteiten zover krijgt een certificaat van abnamro.nl uit te geven kan mensen makkelijk een website voorschotelen die precies lijkt op de website van deze bank. Via een DNS-aanval of een valse omleiding van verkeer met een wifi-hotspot is het niet moeilijk mensen naar deze website om te leiden. Daarmee is één van de twee lagen van de betaling gekraakt. Zodra de tweede laag ook gekraakt is staat weinig meer tussen het geld van de burger en de crimineel.

Oplossingen zijn aanwezig maar Nederland loopt hopeloos achter

Er is een oplossing tegen deze criminele acties: hij heet DANE. Dane is gebaseerd op DNSSEC: één van de fundamentele vernieuwingen die het internet een stuk veiliger gaat maken. Met DNSSEC wordt het vele malen moeilijker iemand naar een vervalste website te loodsen via DNS, doordat antwoorden cryptografisch worden ondertekend. Maar belangrijker is dat DNSSEC een stevige bodem legt voor een nieuwe generatie veiligheidsprotocollen zoals DANE. Met DANE kan de ABN Amro in zijn DNS-zone aangeven welk TLS-certificaat het juiste certificaat is. En omdat de DNS-zone is ondertekend met DNSSEC worden valse certificaten onmogelijk. De TLS-laag is zo weer veilig.

Image

Helaas gaat DANE het in Nederland voorlopig niet redden, want Nederland loopt hopeloos achter bij de uitrol van DNSSEC. Het bovenstaande figuur laat zien dat veilige resolving via DNSSEC wereldwijd rond de 12% ligt. Maar dat je voorloper kunt zijn laat bijvoorbeeld Zuid-Afrika zien met 33%. Nederland zit op ongeveer 5%.

Waarom is Nederland een achterstandsland op digitaal veiligheidsgebied?

Dat ligt niet aan de SIDN, die doen het prima, er zijn inmiddels 1,7 miljoen sites in de .NL zone ondertekend met DNSSEC. Dat is ruim eenderde van alle domeinen. De zwarte (regenboog) Piet ligt bij UPC en andere providers. Internetproviders zoals XS4ALL, UPC, Ziggo en KPN leveren mensen thuis en onderweg toegang tot internet via ADSL, kabel, glasvezel, Wifi, 3G of 4G. Onderdeel van die internettoegang is een DNS-server die domeinen resolved naar IP-adressen. En op die DNS-resovers moet DNSSEC worden aangezet.

XS4ALL heeft dat voor zijn klanten al prima voor elkaar, maar de grotere providers? Mijn provider UPC schreef mij: Hartelijk dank voor uw bericht. U vraagt om het instellen van DNSSEC. Onze excuses voor de onduidelijkheid. Onze systemen bieden geen ondersteuning voor het instellen van DNSSEC. Er zijn ook geen plannen om dit binnenkort te gaan ondersteunen.

Wie trekt ons uit deze impasse?

Mijn oproep aan de politiek: Het is in het belang van de economie en het vertrouwen in online zakendoen dat de digitale infrastructuur in Nederland vertrouwd kan worden. Wanneer Nederland voorop wil lopen in de digitale ontwikkelingen is een vorm van actieve sturing op internet veiligheid hard nodig. Het is onbegrijpelijk dat de Nederlandse providers met dit gedrag wegkomen.

Hans-Cees Speel is hoofd ICT Bureau Jeugdzorg Gelderland en security officer van het nieuwe digitale gezinsdossier Jeugdzorg. Deze column is geschreven op persoonlijke titel van de auteur en reflecteert niet noodzakelijk de zienswijze van Security.NL.

Reacties (51)
08-09-2014, 12:20 door Anoniem
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.
08-09-2014, 12:35 door Erik van Straten
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:
Door Hans-Cees: En omdat de DNS-zone is ondertekend met DNSSEC worden valse certificaten onmogelijk.
"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.

Door Hans-Cees: XS4ALL heeft dat voor zijn klanten al prima voor elkaar
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.
08-09-2014, 12:52 door Anoniem
Hier een test om te controleren of jij (jouw ISP) al (voor je) valideert: https://dnssectest.sidnlabs.nl/ .
08-09-2014, 12:58 door Anoniem
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.
08-09-2014, 13:00 door Anoniem
"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%)
08-09-2014, 13:11 door Anoniem
Hans-Cees Speel is hoofd ICT Bureau Jeugdzorg Gelderland en security officer van het nieuwe digitale gezinsdossier Jeugdzorg.
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.
08-09-2014, 13:58 door Anoniem
Het bovenstaande figuur laat zien dat veilige resolving via DNSSEC wereldwijd rond de 12% ligt. Maar dat je voorloper kunt zijn laat bijvoorbeeld Zuid-Afrika zien met 33%. Nederland zit op ongeveer 5%.
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.
08-09-2014, 14:21 door Anoniem
PKI is een verzamelterm. Ik denk dat je X.509 bedoelt.
08-09-2014, 14:22 door Dick99999
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?
08-09-2014, 14:44 door Anoniem
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...
08-09-2014, 15:45 door Dick99999
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!
08-09-2014, 15:59 door Anoniem
Door Anoniem:Nee.. goed bezig...

DNSSEC en DANE zijn slechts een bouwsteen in een veiligheidsketen. Ze gaan niet al je problemen oplossen, maar scheppen daarvoor wel betere randvoorwaarden.
08-09-2014, 16:11 door Anoniem
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.
08-09-2014, 16:34 door Anoniem
Voorlopig gebruikt security.nl zelf geen dnssec volgens mijn Chrome met extra plugin en die de basis DNS servers gebruikt via mijn SBS server
08-09-2014, 19:07 door Dick99999 - Bijgewerkt: 08-09-2014, 19:12
@ 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.
08-09-2014, 19:17 door Anoniem
Door Anoniem:

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

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.....
08-09-2014, 22:19 door Hans-Cees
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.
08-09-2014, 23:25 door Anoniem
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.
09-09-2014, 01:26 door [Account Verwijderd] - Bijgewerkt: 09-09-2014, 01:38
[Verwijderd]
09-09-2014, 08:31 door Anoniem
Door Anoniem: 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.....
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.


Door Hans-Cees: - Certificaten zouden niet veilig zijn: ja dat is nu net het verhaal achter deze column: daar moeten we dus iets aan doen.
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.

Dit soort zaken zijn geen argumenten IMHO om dus maar niks te doen.
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.


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

Precies waarom er politieke aandacht nodig is: de ICT sector zelf lost dit niet op.
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.
09-09-2014, 09:58 door Anoniem
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.

Door Hans-Cees: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.
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.

Door Hans-Cees:- Certificaten zouden niet veilig zijn: ja dat is nu net het verhaal achter deze column: daar moeten we dus iets aan doen.
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?

Door Hans-Cees:In praktijk gebruikt 99,9% de dns-server die hij/zij via DHCP van zijn provider krijgt. Die moet dus veilig zijn.
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.

Door Hans-Cees:Het argument dat politici niks snappen ...
...is onderschatting en generaliserend. Er zitten in de kamers best wel wat knappe koppen die kunnen communiceren op het niveau van hun soortgenoten.

Door Hans-Cees:Precies waarom er politieke aandacht nodig is: de ICT sector zelf lost dit niet op.
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.
09-09-2014, 10:07 door Anoniem
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
09-09-2014, 10:24 door Anoniem
Door Picasa3: Ik heb xs4all, maar de test zegt dat ik niet beveiligd ben.

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).
09-09-2014, 10:55 door Anoniem
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.
09-09-2014, 13:09 door Anoniem
Door Guido:Zie hier mijn ideeen om met DNSSEC en DANE het phishingprobleem op te lossen
Maar ehm... "mijn ideeen"?
Volgens mij slechts een visualisatie van DANE, niet?
09-09-2014, 14:33 door Anoniem
Door Anoniem:
Door Picasa3: Ik heb xs4all, maar de test zegt dat ik niet beveiligd ben.

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

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

Pierre.
09-09-2014, 16:26 door Anoniem
Relevant: http://dnssec.nl/cases/dnssec-inventarisatie-grote-verschillen-tussen-sectoren-1.html
09-09-2014, 16:31 door Anoniem
Door Anoniem: Het aantal browsers waar DANE standaart in ondersteund wordt is exact 0 (zegge: "nul").

Dat is dus niet helemaal waar:

https://www.dnssec-tools.org/wiki/index.php/Bloodhound
09-09-2014, 16:40 door Anoniem
Door Anoniem:
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.

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.
09-09-2014, 21:18 door Anoniem
Door Anoniem:
Door Anoniem: Het aantal browsers waar DANE standaart in ondersteund wordt is exact 0 (zegge: "nul").

Dat is dus niet helemaal waar:

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

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.
09-09-2014, 21:25 door Anoniem
Door Anoniem:
Dat is dus niet helemaal waar:

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.
09-09-2014, 23:07 door Anoniem
Door Anoniem:
Door Guido:Zie hier mijn ideeen om met DNSSEC en DANE het phishingprobleem op te lossen
Maar ehm... "mijn ideeen"?
Volgens mij slechts een visualisatie van DANE, niet?

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)
10-09-2014, 11:20 door Anoniem
Door Anoniem:
Door Anoniem:
Dat is dus niet helemaal waar:
Helaas vind ik geen .exe of .dmg, maargoed, het is een begin.

Gewoon bij downloads:

http://www.dnssec-tools.org/download/bloodhound-26.0.1.en-US.mac64.dmg
10-09-2014, 11:23 door Anoniem
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.
10-09-2014, 14:06 door wizzkizz
Door Anoniem: 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.
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.
10-09-2014, 15:43 door Anoniem
Door wizzkizz:
Door Anoniem: 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.
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.

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.


[..]

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.

Ze _kunnen_ ook grootschalig gebruikt worden , op een smartcard in een bedrijfsomgeving voor gebruikers login en authenticatie.
(samen met een passphrase/pin ).
10-09-2014, 16:18 door Anoniem
Door Dick99999: 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!

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!
10-09-2014, 18:29 door wizzkizz
Door Anoniem:
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.
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):
Via een DNS-aanval of een valse omleiding van verkeer met een wifi-hotspot is het niet moeilijk mensen naar deze website om te leiden.
11-09-2014, 05:07 door Anoniem
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...
11-09-2014, 23:21 door Hans-Cees
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.
12-09-2014, 02:31 door Anoniem
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.
12-09-2014, 20:46 door Anoniem
Door Anoniem:Denk je nu echt dat men een technologische oplossing kan verzinnen tegen stupide handelingen van mensen?

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.
12-09-2014, 21:06 door Anoniem
Hoi Hans Cees,

Wanneer wordt 'jeugdzorgnederland.nl' voorzien van DNSSEC?
(en waarom geeft https://wijz.jeugdzorgnederland.nl/ andere content dan http://wijz.jeugdzorgnederland.nl/ ?)
12-09-2014, 22:29 door Anoniem
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.
15-09-2014, 10:21 door Anoniem
DNSSEC grootschalig implementeren doet mij denken aan het verlangen dat ieder domein van SPF records voorzien zou zijn...
En de haalbaarheid ervan dus ook.
15-09-2014, 10:28 door Anoniem
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.
15-09-2014, 16:31 door Anoniem
Door Anoniem: DNSSEC grootschalig implementeren doet mij denken aan het verlangen dat ieder domein van SPF records voorzien zou zijn...

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.
17-09-2014, 17:07 door Anoniem
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).
20-09-2014, 15:01 door Hans-Cees
Door Anoniem: DANE kan een goede basis vormen voor een veiliger internet.


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.

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.
22-09-2014, 12:56 door Anoniem
Door Anoniem: 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 automatisering van het proces is een vereiste.

Ook zal het gebruik van DNSSEC de benodigde bandbreedte voor DNS doen exploderen, belasting 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...

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.
04-09-2015, 23:48 door Anoniem
Al iets veranderd?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.