TLSA- en CAA-records uitgelegd

Eerst een brief die de deur uit gaat

Stel, u stuurt een mail naar iemand bij een ander bedrijf. Wat er dan gebeurt, lijkt in niets op wat u ziet. Uw mailserver kijkt eerst in het telefoonboek van het internet — dat is DNS — en vraagt: waar levert post voor dit domein af? Hij krijgt een adres terug, gaat daarheen, klopt aan, en draagt uw bericht over aan de server die opendoet.

In dat verhaal zitten twee aannames verstopt, en beide zijn zwakker dan u zou hopen. De eerste: dat het antwoord uit het telefoonboek klopt. De tweede: dat degene die opendoet ook echt is wie hij zegt te zijn.

De rest van dit artikel gaat over die tweede aanname, en over de twee records waarmee u er iets aan doet. Maar we komen op de eerste terug, want zonder dat fundament is de rest decoratie.

Het pasje bij de deur: wat een certificaat eigenlijk is

Als uw mailserver verbinding maakt met de ontvangende server, wordt dat gesprek versleuteld. De ontvangende server laat daarvoor een certificaat zien. U kunt dat zien als een pasje: er staat een naam op, en er staat een handtekening onder van een partij die zegt dat die naam klopt. Zo'n partij heet een certificaatautoriteit, afgekort CA; in dit beeld is zij de pasjesfabriek. Let's Encrypt is er een, en er zijn er wereldwijd tientallen.

Het pasje hoort bij een sleutel. Het certificaat bevat de publieke helft van een sleutelpaar; de private helft staat op de server en verlaat die nooit. Alleen wie die private helft heeft, kan bewijzen dat het pasje van hem is. Dat is het hele mechanisme: niet het papier telt, maar dat iemand kan aantonen dat hij de bijbehorende sleutel bezit.

En in díe tweede aanname zitten precies twee zwakke plekken. Eén: er zijn tientallen CA's, en in principe mag elk van hen een pasje uitgeven met úw naam erop. Twee: uw verzendende server heeft geen idee welk pasje hij zou moeten verwachten, dus hij gelooft elk pasje met een geldige handtekening eronder.

TLSA gaat over dat tweede probleem, CAA over het eerste. We nemen ze in die volgorde, omdat het tweede probleem bij mail het scherpst zichtbaar is.

Waarom versleuteling bij mail zo makkelijk wegvalt

Bij een website merkt u het meteen als er iets mis is: het slotje verdwijnt, of de browser gooit een waarschuwing voor uw neus. Mailservers onderling hebben die luxe niet. Zij spreken SMTP, een protocol dat is ontworpen in een tijd dat versleuteling nog geen thema was. Versleuteling is er later bijgekomen, met een commando dat STARTTLS heet, en dat commando is een aanbod: de ontvangende server zegt "ik kan versleutelen", en de verzender gaat daar op in.

Een aanbod is weg te nemen. Wie tussen die twee servers zit, haalt het STARTTLS-aanbod uit het gesprek, en de verzendende server ziet een ontvanger die kennelijk geen versleuteling kan. Dan gaat de post gewoon onversleuteld door. Er komt geen waarschuwing, want niemand is iets vreemds opgevallen — er stond immers nooit iets anders in het gesprek.

Dat is het gat. Niet dat de versleuteling gekraakt wordt, maar dat ze beleefd wordt uitgeschakeld en niemand het merkt.

TLSA: het briefje op de deur

TLSA lost dat op met een verrassend simpel idee. U legt in dat telefoonboek een briefje bij, waarop staat welk pasje de ontvangende server hoort te tonen. Een verzender die dat briefje leest, weet nu twee dingen die hij eerst niet wist: dat er versleuteld moet worden, en welk certificaat daarbij hoort. Wordt er iets anders getoond, of helemaal niets, dan gaat de post niet door.

Het briefje staat niet bij uw domein, maar bij de mailserver waar uw MX-record naar wijst — het record dat vertelt waar post voor uw domein wordt afgeleverd. De naam bevat de poort en het protocol:

_25._tcp.mail.voorbeeld.nl.  IN  TLSA  3 1 1 <vingerafdruk>

Poort 25 is de poort waarop mailservers elkaar aanspreken, TCP is het protocol. Dan volgen drie cijfers en een lange reeks tekens. Die drie cijfers zijn wat de meeste uitleg onbegrijpelijk maakt, dus hier staan ze in gewone taal:

1. Het eerste cijfer zegt wat er vergeleken wordt. Bij 3 wijst het briefje rechtstreeks het pasje van de server aan. Geen omweg langs de vraag welke CA het heeft uitgegeven — dit pasje, punt. Dat heet DANE-EE, naar DANE: de naam van de techniek die certificaten aan DNS koppelt.
2. Het tweede cijfer zegt waaraan het pasje herkend wordt. Bij 1 gaat het niet om het pasje zelf maar om de sleutel erin. Dat lijkt een detail, maar het is het belangrijkste deel van het record; verderop leest u waarom.
3. Het derde cijfer zegt hoe er wordt afgekort. Bij 1 wordt er een vingerafdruk van gemaakt met SHA-256. Die vingerafdruk is de lange reeks tekens erachter.

Vandaar 3 1 1. Dat is niet zomaar de populairste combinatie: RFC 7672, de standaard die DANE voor mail beschrijft, beveelt die combinatie met zoveel woorden aan voor SMTP-servers. De twee varianten die daarnaast nog willen leunen op de publieke lijst van vertrouwde CA's, worden daar juist afgeraden: mailservers onderling hebben zo'n bruikbare gedeelde lijst niet.

Waarom dat tweede cijfer over onderhoud gaat

Certificaten verlopen. Die van Let's Encrypt na negentig dagen, en ze worden automatisch vernieuwd. Zou het briefje de vingerafdruk van het pasje bevatten, dan klopt het na elke vernieuwing niet meer, want een nieuw pasje heeft een nieuwe vingerafdruk. U zou dan bij elke vernieuwing ook DNS moeten bijwerken, op tijd, foutloos, jaar in jaar uit.

Door de vingerafdruk over de sleutel te nemen, verdwijnt dat probleem grotendeels. Een certificaat mag opnieuw worden uitgegeven op dezelfde sleutel, en dan blijft de vingerafdruk gelijk. Het briefje blijft kloppen zonder dat er iemand aan te pas komt.

Dit is ook de reden dat DANE-EE nog iets doet wat contra-intuïtief is: een verzender die op dit briefje afgaat, negeert de vervaldatum van het certificaat en controleert niet of de naam erop klopt. Dat klinkt als een versoepeling, maar het is een verschuiving: de geldigheid komt niet meer van de CA, maar van de handtekening onder uw DNS. Wat ons bij het fundament brengt.

Het fundament: waarom DNSSEC geen optie is

Ga even terug naar de eerste aanname, die we hadden laten liggen: dat het antwoord uit het telefoonboek klopt. Als een briefje op de deur bepaalt of post wordt afgeleverd, dan is de volgende vraag onvermijdelijk — wie kan er een briefje ophangen? Kan een aanvaller het uwe weghalen of vervangen, dan heeft u het probleem alleen maar verplaatst.

DNSSEC is het antwoord: het zet een digitale handtekening onder uw DNS-antwoorden, zodat een ontvanger kan controleren dat wat hij leest ook echt van u komt. Zonder die handtekening is een TLSA-record geen beveiliging maar een suggestie.

En dat is geen theoretisch bezwaar, want DANE voor mail is bewust opportunistisch opgezet. Vindt een verzender geen ondertekend TLSA-record, dan weigert hij niet — hij doet precies wat hij vroeger deed en levert af zoals het uitkomt. Een aanvaller die uw ongetekende briefje wegneemt, veroorzaakt dus geen storing die iemand opvalt. Hij zet de beveiliging uit, stilletjes, en dat was nu juist de aanval waartegen u zich wilde wapenen.

De volgorde is daarom niet onderhandelbaar: eerst de zone ondertekenen met DNSSEC — de zone is alles wat er in DNS voor uw domein staat — en daarna pas TLSA. Andersom is het werk zonder opbrengst. Datzelfde geldt trouwens een stap eerder in de keten: ook de MX-lookup zelf moet ondertekend zijn, anders wijst een aanvaller u simpelweg naar zijn eigen mailserver — mét een kloppend briefje op díé deur.

De storing die u een keer zult tegenkomen

Nu het eerlijke deel, want dit record kan uw mail ook tegenhouden. Bijna elke DANE-storing ontstaat op dezelfde manier: er wordt een certificaat vernieuwd mét een nieuwe sleutel, terwijl in DNS nog de vingerafdruk van de oude staat. Vanaf dat moment weigeren alle verzenders die controleren om af te leveren.

Het venijn zit in de timing. De storing komt niet op de dag dat u het record aanzet — dan klopt alles nog. Hij komt bij de eerste automatische certificaatvernieuwing, twee of drie maanden later, als niemand meer aan dat record denkt en het al lang "af" is.

De post belandt nadrukkelijk niet in een spamfilter. De standaard schrijft voor dat zo'n verzender niet terugvalt op onbeveiligde levering; dat zou het hele punt ondergraven. De post wordt eerst uitgesteld en blijft in de wachtrij staan. Microsoft probeert het bijvoorbeeld nog een etmaal en stuurt daarna pas een foutmelding terug naar de afzender. Erger nog: omdat lang niet elke verzender controleert, komt een deel van uw post gewoon binnen. U merkt het dus niet aan een lege inbox, maar aan een klant die zegt dat hij al dagen niets van u hoort.

Er zijn twee manieren om dit te voorkomen, en ze sluiten elkaar niet uit. De eerste is de sleutel behouden bij vernieuwing, want dan verandert de vingerafdruk niet. De tweede is een nette overgang: publiceer het nieuwe record naast het oude, wacht minstens twee keer de TTL — de houdbaarheidstijd die u zelf aan het record meegeeft — zodat overal ter wereld de oude kopieën verlopen zijn, zet dan pas het nieuwe certificaat live, en haal het oude record er daarna weg. Die volgorde staat zo beschreven in RFC 7671, het document met de operationele richtlijnen bij DANE.

Wie kijkt er eigenlijk naar dat briefje?

Een terechte vraag, want een briefje dat niemand leest verandert niets. Het antwoord is: genoeg partijen om het de moeite waard te maken, maar lang niet iedereen.

Microsoft controleert het bij uitgaande post vanuit Exchange Online, standaard en voor alle klanten. Google publiceert geen ondersteuning voor DANE en zet in op MTA-STS, een andere aanpak voor hetzelfde probleem. Ook de andere kant op staat Google buitenspel: de zones van google.com en gmail.com zijn zelf niet met DNSSEC ondertekend, dus wie post naar Gmail stuurt vindt daar geen briefje om op af te gaan. Dat is na te gaan met een DS-opvraging: die laat zien of een zone ondertekend is.

In Nederland ligt de lat hoger dan elders. Voor overheden staat de combinatie STARTTLS en DANE sinds 2016 op de pas-toe-of-leg-uit-lijst van Forum Standaardisatie, sinds 2018 ook voor verzendende servers. Dat is aan de records te zien: kijkt u bij de mailservers van de Belastingdienst of de politie, dan vindt u daar gewoon TLSA-records staan. Levert u aan die markt, dan is DANE geen curiositeit maar een eis; welke vragen u daarover aan uw hoster stelt, staat in DANE bij uw hoster.

CAA: wie mag er überhaupt een pasje maken?

Tijd om terug te komen op die andere zwakke plek, want die staat los van mail en raakt net zo goed uw website. Er zijn wereldwijd tientallen certificaatautoriteiten, en zonder verdere maatregelen mag elk van hen een certificaat uitgeven met uw domeinnaam erop. Niet omdat ze dat zomaar doen, maar omdat er niets is dat het tegenhoudt. Eén CA die zich laat misleiden of een fout maakt in de controle, en er ligt een geldig pasje met uw naam erop bij iemand anders.

CAA is het bordje bij de fabriek in plaats van bij de deur. U zet in DNS welke CA's voor uw domein mogen uitgeven, en elke CA is verplicht dat te lezen voordat zij een certificaat afgeeft. Dat is geen vrijblijvende afspraak: het staat sinds 8 september 2017 in de Baseline Requirements van het CA/Browser Forum, de regels waar publiek vertrouwde CA's zich aan moeten houden. Wat een CAA-record precies mag bevatten staat in RFC 8659.

Zo ziet het eruit — en dit is het echte record van hostage.nl, dus u kunt het natrekken:

hostage.nl.  IN CAA  0 issue     "letsencrypt.org"
hostage.nl.  IN CAA  0 issuewild "letsencrypt.org"
hostage.nl.  IN CAA  0 iodef     "mailto:security@hostage.nl"

De eerste regel zegt: alleen Let's Encrypt mag certificaten voor dit domein uitgeven. De tweede doet hetzelfde voor wildcardcertificaten, het type dat voor álle subdomeinen tegelijk geldt. De derde is een adres waarop wij bericht willen krijgen als een CA een aanvraag weigert — een gratis waarschuwing dat iemand een certificaat op onze naam probeerde te verkrijgen.

Wat CAA níét doet

Hier gaat het vaak mis in de verwachtingen. CAA werkt uitsluitend op het moment van uitgifte, bij de CA. Het maakt een certificaat dat al bestaat niet ongeldig, en browsers kijken er nooit naar. Het is dus preventie, geen bescherming achteraf. Voor dat laatste bestaat Certificate Transparency, het openbare logboek waarin uitgegeven certificaten worden vastgelegd, zodat u áchteraf kunt zien wat er op uw naam is gemaakt. De twee vullen elkaar aan.

Twee valkuilen die u kunt vermijden

De eerste is de zoekvolgorde. Een CA begint bij de volledige naam en klimt omhoog: eerst www.voorbeeld.nl, dan voorbeeld.nl, en zij stopt bij het eerste niveau waar überhaupt een CAA-record staat. Dat is handig — één record op uw hoofddomein dekt alle subdomeinen — maar het werkt ook de andere kant op. Zet u op een subdomein alleen een iodef-regel, dan stopt de CA daar, vindt geen enkele beperking, en mag iedereen weer uitgeven. Het subdomeinrecord vult de regel van het hoofddomein dan niet aan, maar dekt hem af.

De tweede zit in issuewild. Laat u die weg, dan geldt uw gewone issue-regel ook voor wildcards en is er niets aan de hand. Maar zodra er één issuewild-regel staat, worden bij een wildcardaanvraag álle issue-regels genegeerd. Wie issuewild voor de ene CA toevoegt naast issue voor de andere, sluit die andere daarmee ongemerkt buiten.

En de klassieker, tot slot: een CAA-record zetten voor de CA die u vandaag gebruikt, een jaar later overstappen, en dan niet begrijpen waarom de nieuwe leverancier geen certificaat kan afgeven. Verandert u van CA, verander dan eerst het record. Houd er daarbij rekening mee dat een CA haar controle een tijd lang mag hergebruiken, dus een correctie werkt niet altijd meteen.

De twee naast elkaar

Terug naar waar we begonnen. Beide records staan in DNS, beide gaan over certificaten, en ze doen iets volstrekt verschillends:

Die laatste regel is meteen het advies over de volgorde. Een fout CAA-record merkt u zelf, op een moment dat u toch al bezig bent. Een fout TLSA-record merken uw klanten, op een moment dat u nergens mee bezig bent. Begin daarom met DNSSEC en CAA, en zet TLSA er pas bij als het vernieuwen van uw certificaten geregeld is.

Zelf kijken wat er staat

U hoeft niets te installeren om te zien of dit bij uw eigen domein op orde is. De mailtest van internet.nl controleert DNSSEC, DANE, SPF, DKIM en DMARC in één keer en laat per onderdeel zien wat er ontbreekt. Het is een initiatief waar onder meer de Nederlandse overheid en SIDN achter zitten, en in de Nederlandse markt geldt de uitslag in de praktijk als rapportcijfer.

Wilt u de records zelf zien, dan kan dat ook in onze DNS-editor: die kent zowel CAA als TLSA en vult bij een nieuw TLSA-record alvast de gangbare 3 1 1 in, zodat u dat niet hoeft te onthouden.

Veelgestelde vragen