Uitleg TLSA / DANE
Wat is DANE (TLSA)?
Bij een normale TLS-verbinding vertrouw je op certificaatuitgevers (CA's): je server toont een certificaat en de andere kant gelooft het als een bekende CA het heeft ondertekend. DANE (DNS-based Authentication of Named Entities) voegt een tweede anker toe: je legt in je eigen DNS vast wélk certificaat (of welke CA) geldig is. Omdat dat via DNSSEC ondertekend is, kan niemand er ongemerkt mee knoeien. Vooral voor mailservers is dat waardevol, want daar wordt het certificaat van de andere kant van oudsher nauwelijks gecontroleerd.
Hoe het werkt
Je publiceert een TLSA-record op een naam die de dienst en poort aangeeft, bijvoorbeeld _25._tcp.mail.example.com voor mail op poort 25. In dat record staat een 'vingerafdruk' van het certificaat dat je server hoort te tonen, plus drie cijfers die zeggen hoe er gecontroleerd moet worden. Voorbeeld: _25._tcp.mail.example.com TLSA 3 1 1 <vingerafdruk>. Dat is het meest gebruikte type, waarbij de vingerafdruk de publieke sleutel van je server is.
Maakt een andere mailserver verbinding, dan haalt die het TLSA-record op (via DNSSEC, dus betrouwbaar) en vergelijkt het met het certificaat dat jouw server aanbiedt. Komt het niet overeen, dan weigert hij de verbinding. Een tussenpersoon met een ander certificaat komt er zo niet doorheen.
DNSSEC is een harde voorwaarde
DANE staat of valt met DNSSEC. Het hele idee is dat het TLSA-record niet vervalst kan zijn, en die garantie komt van DNSSEC. Zonder DNSSEC negeren verbindende servers je TLSA-record volledig. Het doet dan niets.
Lees daarom eerst de DNSSEC-guide en zorg dat dat goed staat voordat je aan DANE begint.
Waarom vooral voor mail?
Voor websites is DANE zeldzaam: browsers ondersteunen het niet, dus daar leun je op CA's en MTA-STS-achtige mechanismen. Voor mail tussen servers (SMTP) is DANE juist populair, omdat daar lang helemaal geen goede certificaatcontrole bestond. Grote mailpartijen valideren DANE, en in sommige landen is het bijna de standaard geworden.
DANE en MTA-STS lossen ongeveer hetzelfde probleem op. Veel domeinen kiezen er één, sommige doen beide.
Let op: onderhoud en sleutelwissels
Net als DNSSEC is DANE onvergeeflijk: vernieuw je je certificaat maar vergeet je het TLSA-record bij te werken, dan klopt de vingerafdruk niet meer. Iedere verzender die DANE valideert weigert dan de verbinding, en je inkomende mail blijft steken.
Koppel het TLSA-record daarom bij voorkeur aan de publieke sleutel van je server, die je bij elke vernieuwing hergebruikt (het gangbare '3 1 1'-type). Dus niet aan één specifiek certificaat, en liever ook niet aan een tussencertificaat van je CA, want CA's wisselen die geregeld. Moet je sleutel toch om? Publiceer de nieuwe vingerafdruk dan eerst náást de oude, wissel daarna pas, en ruim de oude op.
Veelgestelde vragen
Heb ik DNSSEC nodig voor DANE?
Ja, absoluut. Zonder DNSSEC wordt je TLSA-record genegeerd en doet DANE niets.
DANE of MTA-STS: wat moet ik kiezen?
Beide beveiligen mailtransport. MTA-STS werkt zonder DNSSEC en leunt op HTTPS. DANE vereist DNSSEC en legt het certificaat in DNS vast. Heb je al DNSSEC, dan is DANE een logische keuze. Anders is MTA-STS makkelijker. Beide kan ook.
Werkt DANE voor mijn website?
In de praktijk niet: browsers ondersteunen DANE niet. Het is vooral een mailding (SMTP). Voor websites leun je op CA's en HSTS.
Wat betekent _25._tcp?
Dat geeft de dienst en poort aan: _25 is poort 25 (SMTP) en _tcp het protocol. Het TLSA-record hangt zo aan een specifieke dienst van je server.