Dette indlæg er alene udtryk for skribentens egen holdning.

Bedre SSL-sikkerhed med DNS

27. april 2014 kl. 23:045
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Blev du ramt af Heartbleed? Har du så fået skiftet nøgler og certifikater? Hvad med at få revoket de gamle certifikater? Har du testet at klienter rent faktisk afviser de gamle certifikater? Gik det hele smertefrit?

Denne gang gik det smertefrit fordi alle de involverede har været meget fokuseret på problemet. Men havde det været et lokalt problem der have kompromiteret mine nøgle kunne jeg sagtens have faret vild i en labyrint.

Jeg har tidligere skrevet om at lægge SSL certifikater i DNS for på den måde at give domæneejeren en større kontrol med certifikaterne. Men hvordan foregår det i praksis?

En TLSA-record for en af mine mindre aktive blogs (blog.hacking.dk) ser således ud:

  1. _443._tcp.blog.hacking.dk. IN TLSA ( 1 0 1
  2. 3160F58E03840EF7288F98E04851DF3E8D600DF2F830AEF274D57575926BB0E6 )

Som en del af hostnavnet angives det er der er tale om et certifikat der bruges på port 443 over TCP for hosten blog.hacking.dk. Selve TLSA-recorden består af 3 tal samt certifikatet som hextal.

Artiklen fortsætter efter annoncen

Det første tal angiver hvilken type certifikat der er tale om (kaldes
'certificate usage' i RFC'en). Det kan være et offentligt CA (type 0), et certifikat udstedt af et offentligt CA (type 1), et privat CA (type 2) eller et certifikat der kan være self-signed (type 3). I det ovenstående eksempel har jeg et AlphaSSL-certifikat og bruger derfor type 1, som angiver at certifikatet både skal matche min TLSA-record og valideres normalt.

Det andet tal angiver hvilken del af certifikatet der skal valideres mod TLSA-recorden. Jeg har valgt at validere hele certifikatet. Det tredje tale angiver at TLSA-recorden indeholder en SHA256-sum af certifikatet. Alternativerne er SHA512 eller at man lægge hele certifikatet uhashet i DNS.

For at tage hashsummen af certifikatet er det vigtigt at man bruger den rigtige udgave. Når jeg sætter Apache eller andre servere op bruger jeg oftest certifikatet i PEM format, men for at generere en TLSA-record skal jeg bruge DER format. Det gøres således:

  1. openssl x509 -in wildcard_hacking_dk.crt -outform der | sha256sum

Det hele skal så bare tastes in i min DNS-opsætning. Hvis man bruger en DNS-udbyder til at hoste ens domæne kræver det selvfølgelig at udbyderen understøtter TLSA-records og DNSSEC er selvfølgelig også en forudsætning. De fleste af mine domæner ligger hos GratisDNS der understøtter begge dele.

Artiklen fortsætter efter annoncen

DNSSEC kræver stadigvæk at man holder tungen lige i munden, men derudover er det så let at lægge sine certifikater i DNS at der næsten ikke er nogen undskyldning for ikke at gøre det.

5 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
5
28. april 2014 kl. 17:41

Kom i tanke om at jeg havde læst om en andre måder at gøre noget lignende på for et par år siden som også havde browser understøttelse i chrome:

https://tools.ietf.org/html/draft-ietf-websec-key-pinning-01

http://blog.stalkr.net/2011/08/hsts-preloading-public-key-pinning-and.html?m=1

http://nelenkov.blogspot.com/2012/12/certificate-pinning-in-android-42.html?m=1

Alternativt er der også TACK extension til SSL.

https://lwn.net/Articles/501360/

1
28. april 2014 kl. 09:13

Desvære er der ingen af browserne der rent faktisk bruger TLSA-records til at validere SSL-certifikater, så hvordan tester man at det man har lavet virker?

GnuTLS indeholder et værktøj der hedder danetool, som både kan generere og teste TLSA-records. Det kræver at man har certifikatet liggende, men derefter er det let:

  1. danetool --check=blog.hacking.dk --load-certificate ~/certs/wildcard_hacking_dk.crt

Hvis man ikke har certifikatet liggende kan man selvfølgelig lave en SSL-forbindelse og finde det den vej. For eksempel med 'gnutls-cli -V -p 443 blog.hacking.dk'. Så bliver certifikatet skrevet ud og man kan bare klippe/klistre.

Debian-pakkerne af GnuTLS understøtter ikke DANE på grund af licensproblemer. Det kræver derfor at man selv oversætter GnuTLS med dane slået til. Hvis man bare vil have værktøjerne liggende i source-kataloget er det ligetil, men det er ikke helt trivielt at lave nye debian-pakker med dane slået til.

Jeg tror iøvrigt at jeg skal begynde at bruge 'gnutls-cli' til at teste SSL istedet for 'openssl s_client' det virker som et noget mere brugervenligt værktøj.