Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

18 maart 2015

Tweeluik DANE, deel I: TLSA records voor het web

DANE is een protocol voor het veilig publiceren van publieke sleutels en certificaten dat voortbouwt op DNSSEC . Hoewel DANE dus breder inzetbaar is, doet het op dit moment zijn eerste intrede met name in de wereld van de web-certificaten (HTTPS) en de beveiliging van mail-transport (SMTP). In dit artikel focussen we daarom specifiek op de inzet van DANE voor het beveiligen van TLS — officieel DANE TLSA geheten. Dit eerste deel beschrijft de TLSA records en hun praktische inzet voor websites. In het tweede deel laten we zien hoe DANE gebruikt kan worden om mail gateways cryptografisch te beschermen.

DNSSEC omhelst veel meer dan alleen het beveiligen van de DNS -records. Met DNSSEC wordt een infrastructuur aangelegd die in de toekomst door tientallen andere protocollen gebruikt kan worden om cryptografisch beveiligde informatie over te dragen of bestaande internet-protocollen kan versterken.

Web en mail

Voorbeeld is het drietal DKIM/SPF/DMARC dat phishing, spam, virussen en andere malware tegengaat door de afzender, de verzender en de inhoud van een bericht te valideren. Daarvoor worden diverse nieuwe records in de DNS-informatie opgenomen. Hoewel ondertekening met DNSSEC voor deze toepassing niet strikt noodzakelijk is, is dat wel een belangrijke toevoeging.

Ander voorbeeld is het DANE-protocol dat gebruikt wordt om versleutelde internet-verbindingen van een extra beveiliging te voorzien. Het bijbehorende TLSA record vormt een additionele vertrouwensketen voor de x.509 server-certificaten die voor het opzetten van TLS-verbindingen worden gebruikt. Hier is het gebruik van DNSSEC dan ook een verplicht onderdeel van de standaard zoals vastgelegd in RFC 6698.

HTTPS

Een ernstig probleem met het huidige HTTPS-protocol is dat server-certificaten niet aan een specifieke Certificate Authority (CA, de ondertekenende instantie) zijn gekoppeld. Dat betekent dat elk certificaat dat door een vertrouwde CA is ondertekend door de client als valide wordt beschouwd. De huidige versie van Firefox bevat echter meer dan 100 vertrouwde CA's. Als één daarvan gekraakt wordt, kan in principe voor elk willekeurig domein een vals server-certificaat worden aangemaakt. Het DigiNotar-debacle heeft laten zien dat deze kwetsbaarheid daadwerkelijk tot hele grote veiligheidsproblemen kan leiden. Drie jaar geleden werden via deze CA meer dan 500 valse certificaten verspreid. Dergelijke, zij het kleinschaliger kraken komen regelmatig voor.

Een ad-hoc oplossing is certificate pinning. Daarbij wordt voor belangrijke of veelgebruikte domeinen een apart trust anchor in de browser bijgehouden. Via een vingerafdruk (een hash) kan het server-certificaat of de public key worden vergeleken met een meegeleverde of eerder opgeslagen vingerafdruk. Het domein *.google.com is bijvoorbeeld een hele voordehandliggende om met de browser-software mee te sturen. Certificate pinning blijft echter een niet-structurele oplossing.

DANE

DANE biedt via DNS een veel betere oplossing. Door een vingerafdruk in de DNS-informatie op te nemen wordt via DNSSEC een alternatieve vertrouwensketen (chain-of-trust) opgebouwd. Op die manier kan niet alleen een server-certificaat met een specifieke CA verbonden worden maar ook een specifiek certificaat aan een server-adres worden gekoppeld.

Dat laatste is met name van belang voor self-signed certificaten. Deze hebben geen trust anchor in de browser, zodat ze altijd een waarschuwingsscherm tot gevolg hebben. Door deze met DNSSEC te verankeren, wordt niet alleen die irritante pop-up voorkomen, maar worden self-signed certificaten in veel gevallen ook een alternatief voor betaalde server-certificaten. Vanzelfsprekend zijn commerciële CA's niet blij met deze ontwikkeling. Goede kans dat self-signed certificaten in de toekomst standaard onderdeel worden van elk domein+website pakket.

Het TLSA record

Een TLSA record bevat niet veel meer dan een vingerafdruk en informatie over de gebruikte cryptografische protocollen. De enige parameter die wat uitleg behoeft is de zogenaamde 'usage'. Deze geeft aan hoe de betreffende vingerafdruk geïnterpreteerd moet worden:

  1. PKIX-TA: Certificate Authority Constraint:
    verankert een specifiek CA-certificaat in de vertrouwensketen (in aanvulling op de traditionele validatie),
  2. PKIX-EE: Service Certificate Constraint:
    verankert een specifiek server-certificaat (in aanvulling op de traditionele validatie),
  3. DANE-TA: Trust Anchor Assertion:
    verankert een specifiek CA-certificaat in de vertrouwensketen, dat daarmee als trust anchor fungeert,
  4. DANE-EE: Domain Issued Certificate:
    verankert een specifiek server-certificaat, dat overeen moet komen met het door de server aangeboden certificaat.

Usage nummer 0 en 1 verankeren een certificaat van respectievelijk een CA of een server in aanvulling op de traditionele validatie met behulp van de trust anchors meegeleverd in de client (de browser). Daarmee wordt het probleem van de gekraakte CA gelocaliseerd (usage 0) of helemaal geneutraliseerd (usage 1). Bovendien worden op deze manier discrepanties tussen de twee vertrouwensketens gesignaleerd.

Usage 2 en 3 werken onafhankelijk van de traditionele TLS-validatie, en dat maakt ze geschikt voor self-signed certificaten. Bovendien kunnen op deze manier clients bediend worden die helemaal geen trust anchors aan boord hebben. Dat geldt bijvoorbeeld voor SMTP clients zoals we in het vervolgartikel zullen zien.

De DANE-standaard schrijft voor dat bij usage 0 en 1 beide vertrouwensketens moeten valideren. Dat levert een probleem op als de ene keten wel en de andere niet goed valideert. Waarschijnlijk krijgt de Internet-gebruiker een pop-up scherm met een waarschuwing en de optie om toch door te gaan. Hoewel DANE wel beschouwd wordt als de opvolger en vervanger van het gebrekkige en bewezen onveilige PKI-systeem, hebben met name de EV-certificaten nog toegevoegde waarde. Ook omdat er nog jaren browsers zullen zijn zonder DANE-ondersteuning — waarbij self-signed certificaten resulteren in een waarschuwing — is de verwachting dat de PKI-certificaten voorlopig niet zullen verdwijnen.

Tools

Het aanmaken van de TLSA records voor een website is een fluitje van een cent. Er zijn twee verschillende tools die we hiervoor kunnen gebruiken. De ene is hash-slinger van Paul Wouters. De ander is ldns-dane, onderdeel van de ldns library van NLnet Labs. Beide toolkits zijn standaard beschikbaar in de RHEL en Fedora repositories.

De snelste manier om met behulp van hash-slinger een TLSA record te genereren is als volgt:

[user ~]$ tlsa --create --output rfc example.nl
Got a certificate with Subject:
    /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.example.nl
_443._tcp.example.nl. IN TLSA 3 0 1
    13f55c63a6169245ae362cef447961bfec131b52541e1aad3330820bfc725fa7

In dit geval krijgen we het record terug voor een self-signed certificaat (usage 3). Let op dat hier het certificaat gebruikt werd dat door de webserver op poort 443 online werd aangeboden. In het algemeen mag je dit alleen doen op dezelfde machine als waar die webserver draait of op een vertrouwd netwerk. Sowieso kun je beter (ook) het certificaat zelf hierbij gebruiken:

--certificate /etc/pki/tls/certs/star.example.nl.cert

De opdracht met behulp van de ldns toolkit is niet veel anders:

[user ~]$ ldns-dane create example.nl 443

_443._tcp.example.nl. 3600 IN TLSA 3 0 1
    13f55c63a6169245ae362cef447961bfec131b52541e1aad3330820bfc725fa7

Dit record moet je vervolgens in de zone file opnemen voor elke naam (ServerAlias) waaronder de betreffende site bereikbaar is. Testen van de DANE set-up kan als volgt:

[user ~]$ ldns-dane verify example.nl 443
192.0.2.26 dane-validated successfully

Wie liever met een online tool werkt voor het genereren van een TLSA record, kan daarvoor op een van deze twee pagina's terecht:

Roll-over

Tenslotte is het hier nog van belang om niet te vergeten het TLSA record opnieuw aan te maken als het server-certificaat wordt vervangen. Daarvoor moet een complete roll-over worden uitgevoerd: Eerst moet het nieuwe TLSA record worden toegevoegd. Nadat de nieuwe RRset overal bekend is, kan het server-certificaat worden vervangen. En pas daarna kan het oude TLSA record worden weggehaald.