Sådan indfører du DNSSEC på dit domæne

Danmark er nu klar til den sikre navneserver-protokol DNSSEC - men er du? Her er de gode råd fra svensk DNSSEC-ekspert.

I juni signerede organisationen ICANN internettets rod med den sikre protokol DNSSEC, og i august skete det samme for dk-domænet. Dermed er det pludseligt begyndt at give mening for danske domæne-ansvarlige at tænke i DNSSEC-baner.

Men er det til at hitte ud af? Og hvad er fordelene? Det svarede den svenske ekspert på området, Fredrik Ljunggren fra Kirei på, da han besøgte København i anledning af konferencen Internetdagen 2010.

LÆS OGSÅNu er .dk-domænet sikret med DNSSEC

Først og fremmest understregede han, at det ikke behøver at være et stort projekt. Man kunne nemlig altid få en leverandør til at sørge for at generere nøgler og sende dem til DK-Hostmaster.

»Det er ikke meget dyrere at gøre det for tusind domæner end for ét domæne. Så leverandørerne vil kunne gøre det for en billig penge,« sagde Fredrik Ljunggren og nævnte, at danske Larsen Data - kendt for GratisDNS - var det mest brugte firma i Sverige til DNSSEC-signering af domæner.

Har man et høj-risiko-domæne, som for eksempel en bank eller en velbesøgt netbutik, ville han dog anbefale, at man selv stod for projektet. Det ville nok kunne klares med en mandemåned, mente han.

Er der ikke nogle pengestrømme at komme efter på ens domæne, som måske bare indeholder en blog eller en firmapræsentation, er DNSSEC ikke så afgørende. Så vil en hacker nemlig næppe forsøge at stjæle besøgende ved at fifle med DNS-adresserne.

Omvendt er der ingen ulemper ved at begynde nu, mente han.

»At være early adaptor vil ikke skade. Men det kan skade at starte for sent. Det bliver vigtigt med DNSSEC senere, og hvis du starter nu, kan du lave begynderfejl nu, hvor det ikke betyder så meget,« forklarede Fredrik Ljunggren.

Udover at tænke på egne behov, er det også generelt set godt at få sat skub i dansk udbredelse af DNSSEC, mente han. Så bryder man den Catch-22, eller hønen og ægget-problematik, der er den største barriere.

Vælger man selv at stå for signering af sit domæne, opfordrer svenskeren til, at man lægger stille og roligt ud.

»Det store spring i sikkerheden er at gå fra usigneret til signeret. Du kan altid gøre det mere kompliceret senere,« lød rådet.

Glem din favorit-editor
Man skal også være opmærksom på, at DNSSEC-opsætning ikke er så tilgivende som at rode med almindelig DNS.

»Med DNSSEC arbejder du med asymmetrisk kryptering. Du kan ikke bare hive din favorit tekst-editor frem og så begynde,« sagde Fredrik Ljunggren.

Har man en autoritativ navneserver, altså en med 'originale' oplysninger, i modsætning til en resolver, der videregiver DNS-data, havde han et par tommelfingerregler til sikkerhedsniveauet.

Styrken af kryptering kunne sættes til RSA1024/SHA1 for mellem-udsatte websites, mens kritiske sider som banker bør bruge RSA2048/SHA256. DSA-kryptering var for dyrt at validere, fortalte han.

Og levetiden for hver signatur bør være to uger for domæner i mellemrisiko-gruppen, mens højrisiko-sider bør skifte hver uge. Til gengæld er det meget sjældent, at det er nødvendigt at skifte nøglerne, fortalte han. Kun hvis der var tegn på, at de måske ikke var sikre længere.

»Hvis nu jeres netværksadministrator siger op og går ud af døren, mens han ikke ser glad ud, er der måske grund til et keyroll,« sagde Fredrik Ljunggren.

Når DNSSEC skal rulles ud, gælder det om at lave et dummy-domæne, og så afprøve alt hvad man kan finde på. Derefter kan det rigtige domæne signeres.

I øvrigt kunne Windows ikke bruges til DNSSEC, lød det.

»Vi har generet dem siden 2005, og de sagde 'vær ikke bekymret - vi har gode folk på sagen'. Men den delvise support for signering, der er i Windows Server 2008 R2 er fuldstændig håbløs,« var Fredrik Ljunggrens vurdering.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jesper Kristensen

Lad være med at implementere DNSSEC på et domæne med mindre det bliver brugt. Tag fx WWW:

Tidligere versioner af webbrowsere gjorde det nemt for brugeren at ignorere en SSL certifikatfejl og besøge webstedet alligevel. Nutidens webbrowsere vil gerne undgå at stille brugeren sikkerhedsspørgsmål, de ikke har en reel chance for at svare på. Derfor vil de gerne ændre SSL certifikatfejl, så det bliver umuligt for en normal bruger at komme uden om dem - lige som med en "Serveren blev ikke fundet"-fejl. Men fordi ældre browsere gjorde det nemt at ignorere fejlen, er der en del sider derude, som indeholder SSL certifikatfejl, og som altså er afhængige af, at de er nemme at omgå i browserne. Webbrowserne er altså ikke i stand til fuldstændigt at afvise fejlbehæftede SSL certifikater, da det ikke er kompatibelt med det eksisterende www.

Med DNSSEC skal vi helst undgå at tilføje nye obskure sikkerhedsdialoger, som brugeren ikke aner hvad betyder. Derfor vil det klart bedste være, hvis der for brugeren ikke var nogen mulighed for at komme forbi fejlbeskeden, hvis DNSSEC-valideringen fejler. Da DNSSEC ikke er så udbredt endnu, kunne dette måske lykkes. Men hvis en masse websteder når at implementere DNSSEC før den første browser når at gøre det samme, risikerer man at nogen af webstederne gør det forkert, og det vil tvinge browserne til at indføre uforståelige sikkerhedsdialoger for brugeren i forbindelse med DNSSEC.

Lad derfor være med at implementere DNSSEC på et domæne før der er reelle brugere af dette domæne, der regelmæssigt udfører DNSSEC-validering.

  • 0
  • 0
#2 Christian Schmidt Blogger

Derfor vil de gerne ændre SSL certifikatfejl, så det bliver umuligt for en normal bruger at komme uden om dem

Hvorfor egentlig? Et https-site med certifikatfejl kan vel ikke regnes som mere usikkert end et http-site uden certifikat. Browseren skal bare sørge for ikke at vise hængelås-ikon, når certifikatet er i uorden.

  • 1
  • 0
#3 Jesper Kristensen

Nej, et https-site med certifikat-fejl er langt mere problematisk end et http-site.

Forestil dig at du skal foretage en onlinebetaling, og får vist en formular til at indtaste kreditkort-data. Siden er over https og er korrekt sikret med hængelås-ikon og det hele. Først efter du er kommet ind på siden med formularen igangsætter man-in-the-middle sit angreb. Når du klikker på Send-knappen for at sende kreditkort-data, kan du se hængelås-ikonet, og formularen sendes over https, så du burde være sikret. Men fordi man-in-the-middle igangsættes lige nu, vil kreditkortdata alligevel blive sendt ukrypteret til angriberen, og eneste indikation er at browseren ikke viser hængelåsen i det millisekund det tager for angriberen at modtage dine kreditkort-data og redirecte dig tilbage til den sikre https-side.

Argumentet for at man bare kan vise usikre https-sider uden hængelås-ikon fremsiges ofte af dem der ikke vil betale for et gyldigt certifikat. Men det ville da også være ok, hvis der bare ikke var brugt med https://. Et self-signed certifikat på en http:// adresse er fint, men selv samme på en https:// adresse er ikke. Sikre hjemmesider er afhængige af at https:// rent faktisk er sikkert.

Af samme årsag er der mange brugere der tror det er ok at tillade et ukendt certifikat på en side https://a.dk/, fordi det de har at gøre på a.dk alligevel ikke kræver så stor sikkerhed. De ved bare ikke at ved denne handling er det ikke kun a.dk side der indlæses på usikker vis. Også den netbank https://b.dk/ de har åben i et helt urelateret faneblad eller måske først åbner langt senere bliver påvirket, fordi b.dk måske kommunikerer med a.dk og tror at a.dk er sikker.

  • 0
  • 0
#4 Kurt Mielke

Men fordi man-in-the-middle igangsættes lige nu, vil kreditkortdata alligevel blive sendt ukrypteret til angriberen, og eneste indikation er at browseren ikke viser hængelåsen i det millisekund det tager for angriberen at modtage dine kreditkort-data og redirecte dig tilbage til den sikre https-side.

Det er forkert. Klienten sender data krypteret med den nøgle, som er aftalt for SSL-sessionen, mellem den rigtige server og clienten. Også selv om certificatet er self-signed, skal du have den private nøgle fra serveren (hvis vi undtager de kendte (og måske ukendte) fejl med man-in-middle attack) og lyttet med på sessionen (pass-through), for at kunne dekryptere det klienten sender. Siden skal mangle hængelåsen, eller være fejlkodet til at sende data til en anden host end den hængelåsen er sat for, for at noget sådan kan ske Jeg forstår ikke dit eksempel med a og b. Hvorfor og hvordan skal en højsikker hjemmeside b kommunikere med en anden hjemmeside, som slet ikke er sikret. Jeg ved, at i Firefox, er det ikke a du siger god for, men alene det ene certifikat som a. præsenterer. Dvs. overtages kommunikationen af en mellemmand, eller lign. skal du godkende brugen af et nyt certifikat. Om det er anderledes i andre browsere ved jeg ikke.

  • 0
  • 0
#5 Jesper Kristensen

"Klienten sender data krypteret med den nøgle, som er aftalt for SSL-sessionen, mellem den rigtige server og clienten."

Nej, hvis certifikatet er self-signed kan browseren jo ikke vide om serveren er den rigtige.

"Også selv om certificatet er self-signed, skal du have den private nøgle fra serveren"

Men den har du jo, da du selv som angriber har genereret nøglen og tilhørende self-signed certifikat.

"Hvorfor og hvordan skal en højsikker hjemmeside b kommunikere med en anden hjemmeside, som slet ikke er sikret."

Den højsikrede hjemmeside b kan sagtens kommunikere med en anden højsikret hjemmeside a, og det er ikke så sjældent igen at det sker. Men hvis browseren accepterer et self-signed certifikat er den anden side a lige pludselig ikke længere højsikret, selvom b har taget alle forholdsregler for at sikre at a er sikret.

"Jeg ved, at i Firefox, er det ikke a du siger god for, men alene det ene certifikat som a. præsenterer."

Ja, men certifikatet behøver ikke være ændret i det eksempel jeg gav.

Se også fx http://blog.johnath.com/2008/08/05/ssl-question-corner/

  • 0
  • 0
Log ind eller Opret konto for at kommentere