Tips en trucs voor DANE TLSA
Gepubliceerd op 24-01-2017
door Wido Potters, BIT
Eind 2016 hebben we bij BIT het DNS -based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol — kortweg TLSA — geconfigureerd voor een aantal hosts. In dit artikel geven we een paar tips voor de implementatie ervan.
Probleem
TLSA is een protocol voor het veilig publiceren van publieke sleutels en certificaten dat voortbouwt op DNSSEC. DNSSEC voegt cryptografische verificatie toe aan het DNS en maakt het daarmee een betrouwbare bron voor certificaateigenschappen. Met DNSSEC is het Domain Name System veilig gemaakt en worden valse antwoorden op vragen aan het DNS voorkomen.
Certificaten worden onder andere gebruikt voor websites die HTTPS (TLS) ingeschakeld hebben. Die certificaten worden verstrekt door certificaatautoriteiten die met veel of weinig moeite controleren of jij wel daadwerkelijk de eigenaar/beheerder bent van de Domeinnaam waar je een certificaat voor aanvraagt. Er zijn echter meer dan 100 certificaatautoriteiten die door browsers worden vertrouwd. Een probleem bij een van die autoriteiten kan tot gevolg hebben dat er valse certificaten worden uitgegeven voor grote en kleine sites. Onder andere Comodo en Diginotar hebben in het verleden valse certificaten uitgebracht. TLSA voorkomt niet de uitgifte van valse certificaten maar beperkt wel het gebruik ervan.
Betrouwbare bron
Het gebruik van het DNS als betrouwbare bron voor bepaalde informatie met betrekking tot een domein kennen we al langer. Denk bijvoorbeeld aan de publicatie van SPF en DKIM records in het DNS. TLSA zorgt ervoor dat het DNS — maar alleen de veilige variant ervan, DNSSEC — een betrouwbare bron wordt voor de vraag of een certificaat op een website wel of niet vals is.
TLSA
Een TLSA-record bestaat uit vijf vaste onderdelen. Het eerste onderdeel specificeert het poortnummer, het transportprotocol en de host waarvan het certificaat gecontroleerd moet worden. Dat gaat in het formaat '_POORTNUMMER._TRANSPORTPROTOCOL.HOST', bijvoorbeeld '_443._tcp.www.bit.nl'.
In een TLSA-record kan je op verschillende manieren vastleggen wie de certificaatautoriteit voor een certificaat dient te zijn en/of welk certificaat er exact gebruikt wordt. Zie de RFC voor een uitstekende uitleg van de mogelijkheden voor het tweede onderdeel van het TLSA-record: het veld voor certificaatgebruik.
Het derde onderdeel, de selector, specificeert welk deel van het certificaat gecontroleerd moet worden. Het matching type is onderdeel vier en specificeert hoe er gecontroleerd wordt. Het laatste onderdeel is ofwel de ruwe data zelf of een hash van die data.
Een volledig record zou er bijvoorbeeld zo uit kunnen zien:
_443._tcp.www.bit.nl IN TLSA 3 0 1
368BB5751B0382C8AAD4C58125997C21FE926D2349384DBBB063823D 34CD5945
Welke keuzes je maakt voor de verschillende onderdelen is afhankelijk van je certificaatgebruik. Als je 'Let's Encrypt' certificaten gebruikt die een korte geldigheidsduur hebben, zal je de certificaatautoriteit willen vastleggen en niet het exacte certificaat. Als je daarentegen geautomatiseerde toegang hebt tot je DNS, zou je ook voor kortlopende certificaten het exacte certificaat kunnen vastleggen.
Hash
Er is software beschikbaar voor het creëren van een TLSA-record. OpenSSL kan de hash voor je uitrekenen, maar makkelijker is de door Stichting NLNet beschikbaar gestelde tool: 'ldns-dane'. Vooral handig bij geautomatiseerde processen en onderdeel van het Linux package 'ldnsutils'. Maar er zijn meer tools beschikbaar. Een andere mogelijkheid is de door Shumon Huque beschikbaar gestelde online tool.
Monitoring
Op een door SIDN Labs opgezette website kan je controleren of je voor je website een correct TLSA-record hebt gezet. Voor continue monitoring zijn er Nagios/Icinga plugins beschikbaar die controleren of je TLSA-record nog matcht met je certificaat. Voor klanten van BIT die een monitoringdienst afnemen en TLSA-records geconfigureerd hebben staan, kan BIT het TLSA-record opnemen in de te monitoren services. Overigens gebruiken wij daar de ldns-dane functionaliteit voor in een zelf geschreven plugin.
Ondersteuning
De ondersteuning van browsers op het gebied van TLSA blijft nog enigszins achter. Middels add-ons, bijvoorbeeld die van die van CZ.NIC, kan deze functionaliteit echter wel toegevoegd worden. De mailservers Postfix en Exim hebben TLSA-ondersteuning (experimenteel) ingebouwd. Omdat DANE afhankelijk is van DNSSEC, zien we dat het gebruik van TLSA-records met name in Nederland — waar relatief heel veel DNSSEC-enabled domeinen zijn — aanwezig is. Maar het gebruik is desalniettemin nog zeer beperkt. In november 2016 hebben we TLSA geconfigureerd voor onder andere onze MX-servers, hetgeen direct resulteerde in een top-10 plaats voor 'MX host providers by domain count'.
