Tips en trucs voor de implementatie van DANE TLSA

Tips en trucs voor de implementatie van DANE TLSA

04-01-2017 15:44:31

Eind 2016 hebben we al eens geblogd over het DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol, kortweg TLSA. In dit artikel geven we een paar tips voor de implementatie ervan.

Valse certificaten

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.

DNS als 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.

Wat is TLSA?

Een TLSA-record bestaat uit 5 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 oftewel de ruwe data 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.

Software voor een TLSA-record

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 TLSA-record

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 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'.

Mocht je behoefte hebben aan ondersteuning bij het implementeren van TLSA voor jouw diensten, neem dan contact met ons op. We delen graag onze ervaringen als dat het internet ten goede komt. Bij BIT maken we naast DANE TLSA overigens ook gebruik van andere moderne internetstandaarden om vormen van cybercriminaliteit zoals spam, phishing of malware te voorkomen.

 

Door: Wido Potters