Onderwerp: DNSSEC/DANE vs CA

Ik verdiep me een beetje in de de stof mbt DNSSEC/DANE en hoe dit mogelijk een alternatief aan het worden is op de traditionele vertrouwde CA certificaten. Hoewel ik de voordelen snap (onafhankelijk van CA partijen) en een ander voordeel dat genoemd wordt is dat wanneer er een CA lek is (diginotar) dat men een vertrouwd certificaat kan maken en de user hier geen erg in heeft. Bij DNSSEC/DANE heb je een volledige hiërarchie en weet je of de sleutels die je doorkrijgt ook echt bij de betreffende server horen. Echter hier heb ik nog iets wat mij niet helder is.

De sleutels van DNSSEC worden via het DNS aangeleverd aan de client. Indien je bijvoorbeeld op een publieke wifi zit en ook de DNS daar van door krijgt, wat garandeert je dan dat iemand daar niet in heeft zitten bewerken? Ik kan me voorstellen dat je dan als client sowieso DNSSEC moet eisen, maar dan nog: als je het gehele verkeer kunt manipuleren, kun je dan niet ook van root .nl tot het domein valse sleutels voorschotelen aan de client? Bij een CA heb je dan ten minste nog de lokale root certificaten waaraan het getoetst kan worden, en zal men pas bij een lekke CA succes hebben.

Klopt mijn redenatie, of werkt het toch anders?

Voor zover ik weet worden geen sleutels aan cliënt doorgegeven.

Cliënt (laten we zeggen browser van cliënt) vraagt een domein aan. Dan via DNS komt browser tot bv. SIDN aan en krijgt www record + DNSSEC keys voor dat record / domein. Vervolgens gaat browser (DNS) naar de IP adres van de record (dit is feitelijk DNS van hosting provider waar website staat). Daar krijgt DNS tweede deel van de sleutel.

Indien deze twee niet matchen dan stopt je (locale) DNS met resolven en krijg je foutmelding.

Dus indien iemand op openbare wifi DNS spooft zal domein niet resolven.

Zelfs als spoofende DNS juiste keys van je hosting provider DNS zou hebben zou het niet werken omdat SIDN (root servers) niet zouden matchen m.b.t. nameservers welke ingesteld zijn.

Het is dus een goed beveiligd systeem. Wanneer CA ook erin opgenomen wordt dan wordt ook CA op hetzelfde wijze 'bewaakt'.

Hopelijk kan je iets hiermee

Sent from my Nexus 5 using webhostingtalk mobile app

Vergeten belangrijkste om te melden

Indien je eigen DNS (DNS van je internet provider) geen DNSSEC ondersteunt dan valt idd het geheel in water en kan alsnog gespoofed worden (mss bedoelde je dat)?

Maar het is altijd verantwoording van gebruiker om grijze massa in te schakelen.

Ik zou bv nooit via openbare wifi rabo bankieren app gebruiken.

Sent from my Nexus 5 using webhostingtalk mobile app

Oorspronkelijk geplaatst door Arieh

Ik verdiep me een beetje in de de stof mbt DNSSEC/DANE en hoe dit mogelijk een alternatief aan het worden is op de traditionele vertrouwde CA certificaten. Hoewel ik de voordelen snap (onafhankelijk van CA partijen) en een ander voordeel dat genoemd wordt is dat wanneer er een CA lek is (diginotar) dat men een vertrouwd certificaat kan maken en de user hier geen erg in heeft. Bij DNSSEC/DANE heb je een volledige hiërarchie en weet je of de sleutels die je doorkrijgt ook echt bij de betreffende server horen. Echter hier heb ik nog iets wat mij niet helder is.

De sleutels van DNSSEC worden via het DNS aangeleverd aan de client. Indien je bijvoorbeeld op een publieke wifi zit en ook de DNS daar van door krijgt, wat garandeert je dan dat iemand daar niet in heeft zitten bewerken? Ik kan me voorstellen dat je dan als client sowieso DNSSEC moet eisen, maar dan nog: als je het gehele verkeer kunt manipuleren, kun je dan niet ook van root .nl tot het domein valse sleutels voorschotelen aan de client? Bij een CA heb je dan ten minste nog de lokale root certificaten waaraan het getoetst kan worden, en zal men pas bij een lekke CA succes hebben.

Klopt mijn redenatie, of werkt het toch anders?

DANE levert een (identiteit) van een valide SSL certificaat , of trusted root voor het certificaat voor een domein, waarvan de (hele) DNSSEC keten garandeert dat het gegeven record echt afkomstig is van de nameservers van dat domein.
Oftewel de operator van de DNS voor het domein geeft aan welke certificaten of keten trusted zijn voor dat domein - waar de klassieke default is dat elk van de honderden root CAs in de browser een trusted certificaat voor elk domein kan afgeven.

Ik denk dat je gelijk hebt dat het pad naar de dnssec validerende resolver trusted moet zijn - en als je eerste hop een untrusted pad is zoals publieke wifi, je client zelf een validerende resolver zal moeten zijn/lokaal draaien om de volledige security garanties van DANE te krijgen.

Oorspronkelijk geplaatst door SmilieBG

Vergeten belangrijkste om te melden

Indien je eigen DNS (DNS van je internet provider) geen DNSSEC ondersteunt dan valt idd het geheel in water en kan alsnog gespoofed worden (mss bedoelde je dat)?

Ik denk dat TS wat anders bedoelde - zie mijn antwoord .
Als het pad tussen DNSSEC validerende resolver en client niet vertrouwd is, zie ik (ook) niet hoe de client zich kan beschermen tegen een MITM in dat pad die de dns antwoorden manipuleert .

Maar het is altijd verantwoording van gebruiker om grijze massa in te schakelen.

Ja, maar meer dan goed letten op de hints die het OS en applicatie geven kan de gebruiker toch echt niet doet.
Zelf de URL intypen/uit bookmark halen en opletten op slotjes/groene balk en waarschuwingen niet wegklikken is ongeveer het enige wat de gebruiker echt kan doen.
De rest is wat de software moet garanderen .

Ik zou bv nooit via openbare wifi rabo bankieren app gebruiken.
Sent from my Nexus 5 using webhostingtalk mobile app

*als* je netjes let op de slotjes, zelf de URL kiest en niet doorgaat als de browser waarschuwt e.d. dan moet je prima kunnen bankieren via een potentieel onbetrouwbaar netwerk.
Alles wat er tot nu toe langs komt aan banking trojans richt zich (dus) op het compromitteren van de client , in combinatie met allerhande mis-direction naar nep-sites die typisch geen untrusted netwerk nodig heeft maar via phishing binnen komt.

Dank voor de reacties. Wat mij eerst nog niet duidelijk was is dat ook DNSSEC toetst aan lokaal opgeslagen keys (die van ICANN/ root (.)). Dit kan inderdaad op de resolver van de ISP gebeuren maar ook op de client: http://www.dnssec.nl/cases/dnssec-tr...gebruiker.html al is dat nog in de kinderschoenen.

Ik snap nu verder ook dat het verschil nu neer komt op honderden CA's vs 1tje van icann.

Op zich lijkt mij dit toch een prima techniek, in de praktijk is het alleen nog lang niet zover.