image

ICANN heeft vervangen DNSSEC-sleutels uitgesteld

maandag 2 oktober 2017, 10:20 door Redactie, 6 reacties

ICANN, de organisatie die onder andere verantwoordelijk is voor de verdeling van ip-nummers en domeinen, heeft het vervangen van de geheime DNSSEC-sleutels uitgesteld en een nieuwe datum is nog niet gekozen. De reden is dat naar verwachting een aanzienlijk aantal internetgebruikers die dag in de problemen zou zijn gekomen, zo meldt de Stichting Internet Domeinregistratie Nederland (SIDN).

Het was de bedoeling om op 11 oktober het sleutelpaar dat aan de basis ligt van de hele DNSSEC-infrastructuur te vervangen. Dit sleutelpaar is het vertrouwde startpunt voor de validatie van DNSSEC. Het Domain Name System (DNS) is vergelijkbaar met het telefoonboek en vertaalt onder andere domeinnamen naar ip-adressen. DNSSEC is een verzameling extensies voor het DNS-protocol waarmee DNS-informatie digitaal wordt ondertekend. Het moet voorkomen dat internetgebruikers naar malafide websites worden doorgestuurd. Vanwege de veiligheid moet het sleutelpaar regelmatig vervangen worden. Dit is de eerste keer dat dit gebeurt sinds de introductie van DNSSEC in 2010.

Bij zijn beslissing heeft ICANN gebruik gemaakt van statistieken verzameld met het relatief nieuwe RFC 8145-protocol. Daarmee kunnen validerende resolvers aan een server laten weten welke sleutels zij als trust anchor gebruiken bij het opbouwen van de chain of trust. Op die manier krijgen beheerders van ondertekende domeinen informatie over de voortgang van het vervangen van het sleutelpaar. Volgens de meldingen die nu bij beheerders van de rootservers binnenkomen heeft meer dan 5 procent van de rapporterende resolvers alleen het 'KSK-2010 trust anchor' aan boord.

Dat is een probleem, aangezien na de vervangingsoperatie alle internetdomeinen dan onbereikbaar zijn voor gebruikers van resolvers die nog niet van het nieuwe KSK-2017 trust anchor zijn voorzien. Naar schatting maken wereldwijd zo'n 750 miljoen mensen gebruik van een DNSSEC-validerende resolver. De impact van het doorzetten van een roll-over waar de access providers en netwerkbeheerders technisch nog niet klaar voor zijn zou dan ook groot zijn, aldus SIDN. Op dit moment onderzoekt ICANN samen met de technische internetgemeenschap waarom te veel van de validerende resolvers nog niet zijn voorzien van het nieuwe trust anchor.

Reacties (6)
02-10-2017, 11:11 door Anoniem
Het mag wat mij betreft, best een beetje ruig gaan, met engelen-geduld ga je nooit serieus genomen worden.
Maargoed, inmiddels is DNSSEC dusdaning belangrijk dat een overlijden als gevolg van gebrek aan informatie denkbaar is.
Desondanks, ikzelf had niet afgeblazen.
Want andersom is DNSSEC enorm overrated - als in men wenst graag dat het belangrijk zou zijn, maar -helaas- tonen de cijfers slechts marginaal gebruik.
02-10-2017, 14:52 door Anoniem
Dit is eigenlijk een bijzonder lastig probleem; de systemen die nog de oude key gebruiken, hebben een update nodig.
Als ze de key vervangen, raken die systemen ws de weg kwijt en kúnnen ze niet meer updaten...

Catch 22
02-10-2017, 19:35 door Anoniem
Overal nog veel brakke zooi, te vaak ontbreken van moderne technologie, geen nieuwe(re) beveiligingsmaatregelen.

Nog te veel RC4, nog te veel Poodle, nog te vaak ontbrekende SRI-hashes, certificaat ellende en verkeerde configuraties (niet in de goede volgorde, zwakke ciphers, niet overeenkomstig de SAN, als root op de server geïnstalleerd). Af te voeren script bibliotheken, XSS kwetsbaarheden, php zwakheden, clickjacking, enz. enz. enz.

Om droevig van te worden, maar je kan het niet in ene vervangen, vanwege een update die een paar miljoen lieden zonder internet zou zetten.

Leve de mono-cultuur, leve de slechte educatie, leve het zitten op kennis.

Een (digitale) ideale wereld hebben we nog lang niet.

luntrus
03-10-2017, 12:13 door Anoniem
Ik kan me nog van lang geleden het probleem herinneren van het aanpassen van het OSPF wachtwoord in een netwerk. Zodra je dat begint uit te rollen raken systemen hun verbinding kwijt en kun je er op afstand niet meer bij om ze van het nieuwe wachtwoord te voorzien en uit te rollen, dus je moet bereid zijn om alle systemen tegelijk en met de hand (dus ter plekke) van het nieuwe wachtwoord te voorzien. Dat is best een hele logistieke operatie als het bijvoorbeeld om 3000 netwerkcomponenten door het hele land gaat. Het adagium "vervang wachtwoorden regelmatig" kan wel eens makkelijker gezegd dan gedaan zijn.
04-10-2017, 04:44 door Anoniem
Door Anoniem: Ik kan me nog van lang geleden het probleem herinneren van het aanpassen van het OSPF wachtwoord in een netwerk. Zodra je dat begint uit te rollen raken systemen hun verbinding kwijt en kun je er op afstand niet meer bij om ze van het nieuwe wachtwoord te voorzien en uit te rollen, dus je moet bereid zijn om alle systemen tegelijk en met de hand (dus ter plekke) van het nieuwe wachtwoord te voorzien. Dat is best een hele logistieke operatie als het bijvoorbeeld om 3000 netwerkcomponenten door het hele land gaat. Het adagium "vervang wachtwoorden regelmatig" kan wel eens makkelijker gezegd dan gedaan zijn.

Je had die ellende kunnen besparen door het commando tegelijkertijd naar alle devices te pushen via SNMP, dan had je enkel op de convergence tijd hoeven te wachten met minimale impact.
04-10-2017, 11:32 door Anoniem
Door Anoniem:
Door Anoniem: Ik kan me nog van lang geleden het probleem herinneren van het aanpassen van het OSPF wachtwoord in een netwerk. Zodra je dat begint uit te rollen raken systemen hun verbinding kwijt en kun je er op afstand niet meer bij om ze van het nieuwe wachtwoord te voorzien en uit te rollen, dus je moet bereid zijn om alle systemen tegelijk en met de hand (dus ter plekke) van het nieuwe wachtwoord te voorzien. Dat is best een hele logistieke operatie als het bijvoorbeeld om 3000 netwerkcomponenten door het hele land gaat. Het adagium "vervang wachtwoorden regelmatig" kan wel eens makkelijker gezegd dan gedaan zijn.

Je had die ellende kunnen besparen door het commando tegelijkertijd naar alle devices te pushen via SNMP, dan had je enkel op de convergence tijd hoeven te wachten met minimale impact.

Even beter nadenken voordat je denkt dat je 'gelijktijd' kunt doen .
Met een klein beetje timing probleem gaan devices dichterbij je management locatie eerst, en heb je de rest van het netwerk afgesneden omdat de update daar niet meer doorkomt - (goed zo als je out of band management hebt - maar dat is alleen een cli dus geen snmp ).

Mocht je Cisco's in gedachten hebben : je kunt geen 'commando's pushen met snmp' . Je kunt een configuratie fetch initiëren.
De update is bepaald niet atomic, en het device moet de download server (tftp nog vaak) nog kunnen bereiken .

Op nieuwere Cisco IOS versies (en hopelijk ook andere vendors) kun je meerdere keys met een lifetime configureren, en op die manier een nette key rollover doen.

Maar eerste poster heeft absoluut gelijk dat zo'n massale ospf password update een erg complexe operatie was met een heel grote kans op forse verstoringen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.