E-mailbeveiliging

DANE, kort voor DNS-based Authentication of Named Entities, is een generiek protocol voor het veilig publiceren van publieke sleutels en certificaten. Daarbij bouwt deze standaard verder op de cryptografisch beveiligde DNS-infrastructuur die met DNSSEC wordt aangelegd.

Voor DANE is het DNS-protocol uitgebreid met het TLSA-record. Dat kan worden gebruikt om sleutelinformatie – bijvoorbeeld een hashcode, een digitaal uittreksel – aan een adres/protocol/poort-combinatie te koppelen. Op die manier kan van elke versleutelde internet-service de authenticiteit van het servercertificaat via DNS (+ DNSSEC) worden geverifieerd. Komt de hashcode van het servercertificaat niet overeen met de hashcode in het TLSA-record, dan weet de client dat de verbinding – ondanks de versleuteling – niet te vertrouwen is.

Hoewel DANE breder (d.w.z. algemeen) inzetbaar is, vindt het protocol zijn weg in eerste instantie vooral in de wereld van de webcertificaten (HTTPS) en de beveiliging van mailtransport (SMTP). Waar de implementatie van die eerste toepassing maar niet op gang wil komen, heeft vooral DANE voor mail de afgelopen jaren flink opgang gevonden. Zowel de Postfix- als de Exim-mailserver – samen goed voor 80 procent van de MTA-markt – ondersteunt inmiddels DANE-authenticatie [1, 2] en -validatie. De ondersteuning van DANE door OpenSSL (vanaf versie 1.1) heeft dit soort implementaties veel makkelijker gemaakt.

In maart 2017 publiceerde het Nationaal Cyber Security Centrum (NCSC) de Factsheet 'Beveilig verbindingen van mailservers'. Daarin doen zij de aanbeveling om STARTTLS en DANE in te schakelen, om op die manier het transport van mailberichten te beveiligen. In diezelfde maand initieerden overheid en bedrijfsleven ook de 'Veilige E-mail Coalitie'. Deelnemers in deze coalitie verplichten zich om in hun eigen organisatie en bij hun achterban te werken aan de implementatie van onder andere DNSSEC, DANE en STARTTLS.

Een half jaar eerder al plaatste het Forum Standaardisatie STARTTLS en DANE op de 'pas toe of leg uit'-lijst (ptolu). Dat betekent dat overheidsorganisaties min-of-meer verplicht zijn om deze 2 beveiligingsstandaarden in hun mailinfrastructuur te implementeren. Later kwam daar een zogenaamde Streefbeeldafspraak bij, die inhield dat DANE voor mail uiterlijk eind 2019 bij alle Nederlandse overheidsorganisaties toegepast had moeten worden.

DANE voor mail is een zogenaamd opportunistisch protocol. Dat wil zeggen dat een client die zelf DNSSEC, DANE en STARTTLS ondersteunt zijn verbindingen met een server die STARTTLS-ondersteuning en TLSA-records aanbiedt moet versleutelen. Maar ontbreekt een van deze onderdelen, dan vindt noodgedwongen een fallback naar TLS zonder DANE of zelfs een volledig onbeveiligd transport plaats. Voor mail is het afleveren van berichten immers altijd belangrijker geweest dan de beveiliging van het transport.

Wel impliceert de aanwezigheid van een TLSA-record dat de mailserver TLS ondersteunt, waarmee een downgrade-aanval op de STARTTLS capability van de server wordt voorkomen.

Zowel de Postfix- als de Exim-mailserver – samen goed voor 80 procent van de MTA-markt – kan zo geconfigureerd worden dat deze DANE-validatie doet alvorens mail af te leveren bij een MX-gateway. Dat betekent dat het aanmaken van een TLSA-record voor de MX-gateway op poort 25 (de ontvangende kant) direct een concrete verbetering van de veiligheid oplevert.

Webbrowsers zijn nu voor hun HTTPS-verbindingen volledig afhankelijk van de beveiliging bij de meer dan 100 Certificate Authorities (CA's). Het DigiNotar-debacle, waarbij een digitale inbreker meer dan 500 gewaarmerkte certificaten wist te genereren, heeft ons geleerd dat dit model slechts zo veilig is als de zwakste CA. Andere, minder grote maar vergelijkbare incidenten betroffen Comodo (Tweakers.net), Flame (Tweakers.net), Trustwave (Heise Online), MCS en Turktrust.

Met DANE voor web wordt een parallelle veiligheidsinfrastructuur (vertrouwensketen) opgezet voor X.509, zoals het certificatensysteem (PKI) officieel heet. Dat kan straks niet alleen als aanvulling maar voor veel toepassingen ook als volledige vervanging fungeren. Op deze manier had de hele DigiNotar-affaire kunnen worden voorkomen.

Het TLSA-record is speciaal voor DANE aan de DNS-standaard toegevoegd. Het koppelt sleutelinformatie – bijvoorbeeld een hashcode, een digitaal uittreksel – aan een adres/protocol/poort-combinatie. Op die manier kan van elke internetservice de authenticiteit van het servercertificaat via DNS (+ DNSSEC) worden geverifieerd.

Een TLSA-record bevat niet veel meer dan een digitale vingerafdruk (een hashcode) 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:

0: PKIX-TA: Certificate Authority Constraint: verankert een specifiek CA-certificaat in de TLS-vertrouwensketen (in aanvulling op de traditionele validatie)

1: PKIX-EE: Service Certificate Constraint: verankert een specifiek servercertificaat (in aanvulling op de traditionele validatie)

2: DANE-TA: Trust Anchor Assertion: verankert een specifiek CA-certificaat in de TLS-vertrouwensketen, dat daarmee als trust anchor fungeert

3: DANE-EE: Domain Issued Certificate: verankert een specifiek servercertificaat, 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 gelokaliseerd (usage 0) of helemaal geneutraliseerd (usage 1). Bovendien worden op deze manier discrepanties tussen de 2 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 laatste geldt bijvoorbeeld voor SMTP-clients.

Hoewel DANE voor web en DANE voor mail erg op elkaar lijken, zijn er ook belangrijke verschillen. Waar het gebruik van 'https' in de URL impliceert dat TLS gebruikt moet worden, bestaat er niet zoiets voor mail. Uit een mailadres of de MX-records is immers niets af te leiden over de beveiliging van het transport. Wel impliceert de aanwezigheid van een TLSA-record dat de SMTP-gateway TLS ondersteunt, waarmee een downgrade-aanval op de STARTTLS capability van de gateway wordt voorkomen. Het gebruik van TLS door de client is echter optioneel, waarmee DANE voor mail een zogenaamd opportunistisch protocol blijft. Dat wil zeggen dat een client die zelf DNSSEC, DANE en STARTTLS ondersteunt zijn verbindingen met een server die STARTTLS-ondersteuning en TLSA-records aanbiedt moet versleutelen. Maar ontbreekt een van deze onderdelen, dan vindt noodgedwongen een fallback naar TLS zonder DANE of zelfs een volledig onbeveiligd transport plaats. Zo wordt gewaarborgd dat het afleveren van berichten – waar immers geen mens aan te pas komt – zo veel mogelijk doorgang kan vinden.

DANE usage 0 en 1, waarbij het TLSA-record wordt ingezet om een servercertificaat een extra verankering te geven, mogen voor DANE voor mail niet gebruikt worden. De PKI-verankering biedt voor mail geen meerwaarde ten opzichte van een self-signed-certificaat met een TLSA-anker. Als DNS gecompromitteerd is, kan de aanvaller de TLSA-records immers zodanig veranderen (in usage 2 of 3) dat de validatie van de PKI-vertrouwensketen sowieso niet meer vereist wordt.

Hoewel je voor DANE voor het web een vergelijkbare redenering kunt opzetten, gaan de auteurs van RFC 7672 hierbij uit van de huidige situatie waarin mail-clients in tegenstelling tot webbrowsers niet een min-of-meer gestandaardiseerde verzameling trust anchors aan boord hebben. Bovendien is de rol van HTTPS en SMTP+TLS ook verschillend: voor transacties over het web is de versleuteling cruciaal, terwijl voor mail de betrouwbare aflevering meestal belangrijker is dan de beveiliging van het transport. Vandaar ook liever die opportunistische fallback in beveiliging dan een bounce van het mailbericht. DANE voor mail is zo ontworpen dat het een transparante beveiliging toevoegt die geen extra configuratie, trust anchors of interactie met de gebruiker nodig heeft. De ontwerpers beschouwen DANE dan ook niet als een aanvulling maar als de opvolger en vervanger van PKI-verankering.

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 internetgebruiker in de toekomst een pop-upscherm met een waarschuwing en de optie om toch door te gaan, zoals dat nu ook al gebeurt bij problemen met een TLS-certificaat.

Hoewel DANE voor het web wel beschouwd wordt als de opvolger en vervanger van het gebrekkige en bewezen onveilige CA-systeem, hebben vooral de EV-certificaten nog toegevoegde waarde. Ook omdat er nog jaren browsers zullen zijn zonder DANE-ondersteuning – waarbij self-signedcertificaten resulteren in een waarschuwing – is de verwachting dat de CA-certificaten voorlopig niet verdwijnen.

Het DANE-protocol is vastgelegd in de RFC's 6698 (TLSA), 7218, 7671 en 7672 (voor SMTP).

RFC 7673 definieert het gebruik van DANE voor SRV-records (ter ondersteuning van diverse communicatieprotocollen). RFC 7929 doet dat voor OpenPGP (voor de verankering van publieke sleutels middels OPENPGPKEY-records). En RFC 4255 definieert het SSHFP-record, waarin de publieke sleutel van een SSH-server verankerd kan worden.

In principe kan voor alle mailservers die via TLS of STARTTLS beveiligde verbindingen aanbieden een TLSA-record aangemaakt worden. Zowel de Postfix- als de Exim-mailserver – samen goed voor 80 procent van de MTA-markt – kan zo geconfigureerd worden dat deze DANE-validatie doet alvorens mail af te leveren bij een MX-gateway. Dat betekent dat het aanmaken van een TLSA-record voor de MX-gateway op poort 25 (de ontvangende kant) direct een concrete verbetering van de veiligheid oplevert.

Uitgebreide informatie over de configuratie van DANE voor mail vind je in deze hands-on artikelen:

• De implementatie van DANE op Exim

• De implementatie van DANE voor Postfix

Ook het Platform Internetstandaarden heeft een uitgebreide uitleg gepubliceerd:

• DANE for SMTP how-to

Hoewel TLSRPT tegelijkertijd met MTA-STS is gedefinieerd en door dezelfde partijen, werkt dit mechanisme net zo goed voor DANE voor mail. Heb je DANE al geïmplementeerd [Exim, Postfix], dan kun je TLSRPT dus ook prima zonder MTA-STS gebruiken. Sterker nog: DANE biedt een betere bescherming dan MTA-STS, terwijl de publicatie van een TLSA-record veel minder werk is dan de implementatie van MTA-STS (er vanuit gaande dat je DNSSEC sowieso geïmplementeerd hebt).

Zowel de Postfix- als de Exim-mailserver – samen goed voor 80 procent van de MTA-markt – kan zo geconfigureerd worden dat deze DANE-validatie doet alvorens mail af te leveren bij een MX-gateway. Dat betekent dat het aanmaken van een TLSA-record voor de MX-gateway op poort 25 (de ontvangende kant) direct een concrete verbetering van de veiligheid oplevert.

Uitgebreide informatie over de configuratie van DANE voor mail vind je in deze hands-on artikelen:

• De implementatie van DANE op Exim

• De implementatie van DANE voor Postfix

Ook het Platform Internetstandaarden heeft een uitgebreide uitleg gepubliceerd:

• DANE for SMTP how-to

Je kunt de geldigheid van een DANE-configuratie laten controleren op de Internet.nl-portal of door de DANE SMTP Validator van sys4.

Voor zo ver ons bekend zijn er op dit moment (maart 2023) nog geen mailclients die validatie doen op de servercertificaten voor hun POP-, IMAP- of SMTP-verbindingen.

In principe kan voor alle webservers die via HTTPS beveiligde verbindingen aanbieden een TLSA-record aangemaakt worden.

Uitgebreide informatie over de configuratie van DANE voor web vind je in de volgende artikelen:

• Tweeluik DANE, deel I: TLSA records voor het web

• Tips en trucs voor DANE TLSA

Voor zo ver ons bekend zijn er op dit moment (maart 2023) nog geen breed gebruikte webbrowsers die out-of-the-box DANE-validatie doen op de certificaten van hun HTTPS-verbindingen (de DNSSEC/TLSA Validator plugin wordt niet langer ontwikkeld). Wel kun je de geldigheid van een DANE-configuratie laten controleren op de Internet.nl-portal of onze eigen DANE Validator.

MTA-STS staat voor MTA Strict Transport Security en is gedefinieerd in RFC 8461. Met deze beveiligingsstandaard kan de houder van een maildomein aangeven dat zijn ontvangende mailservers (MX-gateways) TLS-versleuteling ondersteunen. Daartoe neemt hij in zijn DNS-zone een speciaal TXT-record op, met daarin een verwijzing naar een MTA-STS policy-bestand.

Dit policybestand wordt gedurende langere tijd (typisch: weken- of maandenlang) door de client (een verzendende mailserver) in zijn cache bewaard. Is dit bestand eenmaal door de client opgeslagen, dan weet deze dat er iets mis is als een ontvangende mailserver ineens aangeeft geen TLS-versleuteling (meer) te ondersteunen. Zolang het policybestand geldig is, mag de client geen fallback doen naar een onversleutelde verbinding. Daarmee is door de houder dus een extra bescherming tegen downgrade-aanvallen (STRIPTLS) aangebracht op zijn maildomein.

Omdat dit mechanisme pas bescherming biedt nadat het policybestand de eerste keer door de client is binnengehaald en bewaard, spreekt men van Trust On First Use (TOFU). Daarmee lijkt dit mechanisme conceptueel op HSTS voor het web. Belangrijk verschil is wel dat bij het omzeilen van MTA-STS eerst het MTA-STS-record onderschept moet worden en vervolgens de STARTTLS capability moet worden gestript (2 verschillende kanalen), terwijl HSTS zijn beschermende werk pas doet als de HSTS-header na eerder contact bij de web-client is aangekomen (want getransporteerd over hetzelfde kanaal: in-band).

STARTTLS is een zogenaamd opportunistisch protocol. Dat wil zeggen dat een client die TLS ondersteunt zijn verbindingen met een server die TLS aanbiedt (via STARTTLS) moet versleutelen als dat kan. Ontbreekt ondersteuning van TLS aan één of beide zijden, dan vindt de aflevering noodgedwongen plaats over een volledig onbeveiligd transport. Voor mail is het afleveren van berichten immers altijd belangrijker geweest dan de beveiliging van het transport. Met de publicatie van RFC 8314 in 2018 is onversleuteld transport voor zowel SMTP als POP en IMAP echter officieel "obsolete" verklaard.

Met de publicatie van een MTA-STS-record en policy-bestand laat een domeinnaamhouder de buitenwereld weten dat zijn ontvangende mailservers (MX-gateways) TLS-versleuteling vereisen van clients (verzendende mailservers) die dat ondersteunen. De client slaat het policy-bestand gedurende langere tijd (typisch: weken- of maandenlang) op, waarmee downgrade-aanvallen (STRIPTLS) op de STARTTLS capability van de MX-gateways kunnen worden voorkomen. Een client die MTA-STS ondersteunt mag immers geen fallback doen naar een onversleutelde verbinding als het policybestand voor de betreffende server dat niet toestaat.

DANE voor mail biedt een sterkere beveiliging van versleuteld transport dan MTA-STS. Waar MTA-STS alleen vastlegt dat er een TLS-certificaat (en dus de STARTTLS capability) op de server beschikbaar is, legt DANE ook cryptografisch vast welk specifiek certificaat of trust anchor door de server aangeboden moet worden (pinning). Zo bezien is MTA-STS dus alleen zinvol als tijdelijke bescherming tegen downgrade-aanvallen (STRIPTLS) zolang je domeinnaam nog niet met DNSSEC ondertekend is. MTA-STS mag door de client ook nooit gebruikt worden om een mislukte DANE-validatie te overrulen. Vandaar ook dat Microsoft DANE de gouden standaard voor de beveiliging van mailtransport noemt.

De grote maildienstverleners Google en Microsoft zijn de belangrijkste aanjagers achter de ontwikkeling van MTA-STS (en TLSRPT). Beide ondersteunen MTA-STS (en TLSRPT) volledig op hun maildiensten (respectievelijk Gmail en Exchange Online).

Tegelijkertijd noemt Microsoft DANE de gouden standaard voor de beveiliging van mailtransport. Zodra je DNSSEC hebt geïmplementeerd, biedt DANE voor mail immers een veel sterkere (en makkelijker te implementeren) beveiliging dan MTA-STS.

De implementatie van MTA-STS begint met de publicatie van een MTA-STS policybestand. Als je je mail door een externe dienstverlener laat verwerken – dat wil zeggen: als je MX-records naar de mailsystemen van een ander verwijzen – dan maak je in het algemeen ook gebruik van het policybestand van die dienstverlener. Je hoeft dan alleen in een MTA-STS-record naar dat policybestand te verwijzen.

Ben je zelf verantwoordelijk voor de verwerking van je mail, dan maak je een policybestand aan met de volgende inhoud:

version: STSv1
mode: testing
mx: mx1.example.nl
mx: mx2.example.nl
max_age: 86400

Hiermee geef je aan dat de twee genoemde MX-gateways beide TLS ondersteunen. Zolang je in 'testing'-modus zit, zullen clients bij het mislukken van de TLS-verbinding een fallback doen naar een onbeveiligd transport. De instelling van 'max_age' op 86400 seconden (een dag) is een veilige waarde in 'testing'-modus.

Heb je als domeinnaamhouder ook een TLSRPT-record ingesteld – zeer aanbevelenswaardig bij het gebruik van MTA-STS – dan ontvang je straks foutmeldingen van verzendende mailservers bij het mislukken van de TLS-versleuteling, zonder dat de aflevering van mail-berichten in gevaar komt.

Het policy-bestand moet geplaatst worden op deze locatie en bereikbaar zijn via HTTPS:

https://mta-sts.example.nl/.well-known/mta-sts.txt

Hiervoor moet je dus een extra A/AAAA-record of CNAME-record aanmaken, welke verwijst naar de webserver waar het policybestand is ondergebracht (de policy-host). Dit om interferentie van deze server met de reguliere webserver te voorkomen en eventueel naar de policy van een maildienstverlener te kunnen verwijzen.

Hoewel dit record wel gewoon naar de reguliere webserver kan refereren (als die virtuele hosts ondersteunt), zal je voor deze naam (vanwege de verplichte HTTPS-verbinding) toch ook een apart TLS-certificaat moeten laten aanmaken.

Is de publicatie van het MTA-STS policy-bestand eenmaal voor elkaar, dan moet de houder van het maildomein dat ook kenbaar maken voor afleverende mailservers. Daartoe publiceert hij een speciaal TXT-record als volgt (parallel aan de MX-records dus):

_mta-sts.example.nl. IN TXT "v=STSv1; id=2024072200;"

Hierin bevat de 'id' de versie van het policybestand. Deze wordt gebruikt om te zorgen dat een mail-client het policybestand alleen hoeft op te halen als deze veranderd is. Deze 'id' moet je dus aanpassen als (nadat!) de inhoud van het policybestand verandert. Het makkelijkst is om daarvoor een serienummer te gebruiken zoals je dat ook doet voor zonefiles.

Als je voor het policybestand eerder verwees naar de policy-host van je maildienstverlener, kun je ook voor het MTA-STS-record het beste een CNAME-verwijzing opnemen:

_mta-sts.example.nl. IN CNAME _mta-sts.mailprovider.example.

Zo voorkom je dat oude versienummers in je zonefile blijven staan als de dienstverlener zijn policybestand aanpast.

Merk op dat de 2 namen voor de policy-host (mta-sts.example.nl) en het MTA-STS-record (_mta-sts.example.nl) erg op elkaar lijken maar echt verschillend zijn: de policy-host is het adres van een webserver (een host), het '_mta-sts'-label (beginnend met een underscore) verwijst naar een dienst.

Met de publicatie van het MTA-STS-record is MTA-STS gelijk in gebruik gesteld. Draai je eenmaal een tijdje zonder problemen, dan verander je de mode in het policybestand van "testing" naar "enforce" (en pas je dus ook de 'id' in het MTA-STS-record aan).

Om te weten of een en ander naar behoren functioneert, implementeer je naast MTA-STS eigenlijk ook altijd TLSRPT. Met dit mechanisme kunnen houders van maildomeinen meldingen van clients (verzendende mailservers) ontvangen bij het mislukken van de TLS-versleuteling naar hun MX-gateways.

DANE voor mail biedt een sterkere beveiliging van versleuteld transport dan MTA-STS. Waar MTA-STS alleen vastlegt dat er een TLS-certificaat (en dus de STARTTLS capability) op de server beschikbaar is, legt DANE ook cryptografisch vast welk specifiek certificaat of trust anchor door de server aangeboden moet worden (pinning). Zo bezien is MTA-STS dus alleen zinvol als tijdelijke bescherming tegen downgrade-aanvallen (STRIPTLS) zolang je domeinnaam nog niet met DNSSEC ondertekend is. Vandaar ook dat Microsoft DANE de gouden standaard voor de beveiliging van mailtransport noemt.

Om die reden raden we je aan om DNSSEC en DANE te gebruiken als dat mogelijk is. Om je daarbij te helpen, hebben we ook uitgebreide hands-on artikelen gepubliceerd. Heb je DNSSEC eenmaal in gebruik, dan is de implementatie van DANE-validatie meestal heel eenvoudig (het aanzetten van een configuratie-optie). DANE aan ontvangende zijde omhelst niet meer dan de publicatie van een TLSA-record.

Wil je toch MTA-STS-validatie op je verzendende mailserver implementeren, dan moet dat plaatsvinden na de DANE-validatie. Je mag immers geen berichten doorlaten die wel op MTA-STS valideren maar niet op DANE. Voor Postfix is de postfix-mta-sts-resolver daemon beschikbaar, zij het dat die op dit moment DANE overrulet en dus niet aan de specificatie voldoet. Exim ondersteunt MTA-STS helemaal niet. Eventueel kun je naar Mox kijken, een moderne MTA-implementatie die zowel DANE als MTA-STS volledig implementeert.

TLSRPT (gedefinieerd in RFC 8460) is een mechanisme waarmee houders van mail-domeinen foutmeldingen van clients (verzendende mailservers) kunnen ontvangen bij het mislukken van de TLS-versleuteling naar hun MX-gateways. Dit mechanisme is vergelijkbaar met dat van DMARC.

Om TLSRPT-meldingen voor zijn maildomein te ontvangen, publiceert de houder een speciaal TXT-record als volgt (parallel aan de MX-records dus):

_smtp._tls.example.nl IN TXT "v=TLSRPTv1; rua=mailto:tls-rua@example.nl"

Zoals je ziet bevat dit record niet veel meer dan een mailadres waarop gestandaardiseerde berichten voor automatische verwerking kunnen worden afgeleverd. Dit mechanisme is vergelijkbaar met dat van DMARC.

Voor de geautomatiseerde verwerking van de TLSRPT-berichten kun je terecht bij dezelfde dienstverleners die ook DMARC doen.

Hoewel TLSRPT tegelijkertijd met MTA-STS is gedefinieerd en door dezelfde partijen, werkt dit mechanisme net zo goed voor DANE voor mail. Heb je DANE al geïmplementeerd [Exim, Postfix], dan kun je TLSRPT dus ook prima zonder MTA-STS gebruiken. Sterker nog: DANE biedt een betere bescherming dan MTA-STS, terwijl de publicatie van een TLSA-record veel minder werk is dan de implementatie van MTA-STS (er vanuit gaande dat je DNSSEC sowieso geïmplementeerd hebt).

STARTTLS is een zogenaamd opportunistisch protocol. Dat wil zeggen dat een client die TLS ondersteunt zijn verbindingen met een server die TLS aanbiedt (via STARTTLS) moet versleutelen als dat kan. Voor zowel MTA-STS als DANE voor mail geldt dat als ondersteuning van de betreffende beveiligingsprotocollen aan één of beide zijden ontbreekt, versleuteling alleen plaatsvindt als de server een geldig TLS-certificaat aanbiedt. In het slechtste geval vindt de aflevering noodgedwongen plaats over een volledig onbeveiligd transport. Voor mail is het afleveren van berichten immers altijd belangrijker geweest dan de beveiliging van het transport. Met de publicatie van RFC 8314 in 2018 is onversleuteld transport voor zowel SMTP als POP en IMAP echter officieel "obsolete" verklaard.

Met de publicatie van een MTA-STS-record en policybestand of een TLSA-record laat een domeinnaamhouder de buitenwereld weten dat zijn ontvangende mailservers (MX-gateways) TLS-versleuteling vereisen van clients (verzendende mailservers) die dat ondersteunen. Een client die MTA-STS ondersteunt moet zijn verbindingen met een server waarvoor een MTA-STS-policy is ingesteld dus altijd versleutelen. Hetzelfde geldt voor een client die DANE ondersteunt: deze moet zijn verbindingen met een server waarvoor een TLSA-record is gepubliceerd altijd versleutelen. Daarmee kan een downgrade-aanval (STRIPTLS) op de STARTTLS capability van een MX-gateway worden voorkomen. In combinatie met DNSSEC (sowieso verplicht voor DANE) is deze digitale bekendmaking bovendien cryptografisch beschermd.

Het verschil tussen MTA-STS en DANE voor mail zit in de extra beveiliging die DANE biedt voor het TLS-certificaat. Waar MTA-STS alleen vastlegt dat er een TLS-certificaat (en dus de STARTTLS capability) op de server beschikbaar is, legt DANE ook cryptografisch vast welk specifiek certificaat of trust anchor door de server aangeboden moet worden (pinning). DANE koppelt daarvoor het betreffende certificaat middels een TLSA-record aan de DNSSEC-vertrouwensketen. Komt het certificaat of de keten aangeboden door de ontvangende mailserver niet overeen met het kenmerk (een digitale vingerafdruk) vastgelegd in het TLSA-record, dan mag de client (een afleverende mailserver) deze verbinding niet gebruiken.

De pinning van een specifiek TLS-certificaat of trust anchor en de cryptografische koppeling aan de DNSSEC-vertrouwensketen maken het mogelijk om DANE voor mail ook te gebruiken met een self-signed certificaat, iets dat de meeste mail-beheerders ook doen (mail-systemen hebben traditioneel immers geen CA trust anchors aan boord zoals webbrowsers dat wel hebben).

Voordeel van MTA-STS ten opzichte van DANE voor mail is dat MTA-STS ook zonder DNSSEC werkt (daar is het destijds voor ontwikkeld) en dat je MTA-STS in 'testing'-modus kunt zetten en op een deel van je MX-ingangen kunt activeren.

DANE voor mail biedt een sterkere beveiliging van versleuteld transport dan MTA-STS. Bovendien is de publicatie van een TLSA-record veel minder werk dan de implementatie van MTA-STS (er vanuit gaande dat je DNSSEC sowieso geïmplementeerd hebt). Zo bezien is MTA-STS dus alleen zinvol als tijdelijke bescherming tegen downgrade-aanvallen (STRIPTLS) zolang je domeinnaam nog niet met DNSSEC ondertekend is.

Een overweging om MTA-STS toch naast DANE voor mail te implementeren, is dat je daarmee ook mail-clients die wel MTA-STS maar niet DANE valideren bedient.

DKIM, SPF en DMARC gaan phishing, spam, virussen en andere malware tegen door de afzender (een mailadres), de verzender (een mail-systeem) en de inhoud van een mail-bericht te beveiligen. Daarvoor worden diverse nieuwe records in de DNS-informatie opgenomen. Hoewel ondertekening met DNSSEC voor deze toepassing niet strikt noodzakelijk is – dat wil zeggen verplicht volgens de standaarden – is dat wel een belangrijke toevoeging.

Het drietal DKIM/SPF/DMARC is de eerste concrete toepassing van de cryptografisch beveiligde infrastructuur die nu met DNSSEC wordt aangelegd.

Hoewel deze 3 standaarden meestal gezamenlijk worden ingezet, hoeft dat niet per se. Je kunt ook alleen DKIM of SPF inzetten, of DMARC weglaten.

DKIM voorziet de body en de header van elk uitgaand bericht van een digitale handtekening. De publieke sleutel wordt via DNS gepubliceerd, zodat een ontvangende MX-gateway de digitale handtekening kan verifiëren. Zo wordt voorkomen dat kwaadwillenden een bericht namens een ander kunnen verzenden (mail spoofing) of de inhoud van een bericht onderweg kunnen veranderen (message integrity).

SPF voorkomt dat MX-gateways mailberichten accepteren van ongeautoriseerde servers. Daartoe wordt een lijst van geldige adressen via DNS gepubliceerd. Dat zijn typisch de SMTP-gateways die eindgebruikers instellen voor hun uitgaande berichten, maar bijvoorbeeld ook de adressen van een externe dienstverlener die namens een organisatie marketingmail verstuurd. Ontvangende systemen kunnen deze lijst van servers gebruiken om de verzender te controleren voor zij een bericht aannemen.

DMARC is een aanvulling op de andere 2 beveiligingsstandaarden voor mail, DKIM en SPF. DMARC geeft ontvangende MX-gateways een aanwijzing (de policy) hoe om te gaan met inkomende berichten waarvoor DKIM of SPF geen geldige validatie oplevert. Deze kunnen bijvoorbeeld weggegooid worden of in quarantaine worden gezet.

De policy wordt via DNS gepubliceerd. Deze kan bovendien een mailadres bevatten waarop mailsystemen afgewezen berichten kunnen rapporteren. Zo krijgt de beheerder van het betreffende maildomein inzicht in de aflevering van zowel echte als vervalste berichten.

Bedrijven als DMARC Advisor en DMARC Analyzer bieden (tegen betaling) de mogelijkheid om de binnenkomende DMARC-rapportages te verwerken tot keurige statistieken en diagrammen.

https://images.ctfassets.net/yj8364fopk6s/vKIjbML8VVuW3YJJC0gxwg/99031812c5c5df1e9cf5f9637d0c6412/Screenshot_DMARC_Advisor_20231101.png

Screenshot van de applicatie de applicatie van DMARC Advisor.

Maar er zijn inmiddels ook diverse (low-level) open-sourcetools voor de verwerking en analyse van DMARC-rapportages beschikbaar:

• parcedmarc

• TA-dmarc

Het drietal DKIM/SPF/DMARC maakt het mogelijk om de verwerking van mail veel efficiënter te maken. Grote mailverwerkers kunnen de binnenkomende berichten uitsplitsen in 2 grote bakken: berichten van ongeauthentiseerde domeinen of van wel geauthentiseerde domeinen die nog niet eerder gezien zijn enerzijds en bewezen gewenste maildomeinen anderzijds.

Voor die laatste categorie is de verwerking simpel: die berichten kunnen gelijk afgeleverd worden. Berichten van onbeveiligde en nog onbekende domeinen moeten uitvoerig gecontroleerd worden. Daarvoor worden dan meer resources ingezet. Bovendien loont het om even te wachten met de beslissing: een zero-day staat nog op geen enkele blacklist. Er is een grote kans dat de classificatie van een dergelijk bericht even later veel eenvoudiger is geworden. SpamAssassin ondersteunt deze manier van werken nog niet out-of-the-box. Maar het Trusted Domain Project bood wel al de tooling om zoiets zelf op te zetten.

De drijvende kracht achter de snelle adoptie van DKIM/SPF/DMARC zijn de grote mailverwerkers, die veel last hadden van phishing. Die socialmediabedrijven – Facebook is verreweg de grootste mailverwerker ter wereld – bestaan nog niet zo lang, dus die hebben nog een goed geconsolideerde mailinfrastructuur. Dat maakte het relatief makkelijk voor hen om DMARC te implementeren.

Andere grote gebruikers zijn de mailmarketeers – de "legitieme spammers". Zij hebben er groot belang bij dat hun berichten aankomen. Bovendien is het inherent aan hun business dat zij een goed gedefinieerde en moderne mailinfrastructuur hebben.

Naarmate meer mailverwerkers DKIM/SPF/DMARC implementeren, wordt het voor domeinnaamhouders belangrijker om die DNS-records te publiceren. Niet meedoen betekent immers dat berichten misschien niet aankomen.

Uitgebreide informatie over de configuratie van DKIM, SPF en DMARC vind je in deze hands-on artikelen:

• De implementatie van SPF, DKIM en DMARC in Exim

• De implementatie van SPF, DKIM en DMARC voor Postfix

Daarnaast kunnen we deze testportaal aanbevelen:

• Learn and test DMARC Deze test maildomeinen op de ondersteuning en goede werking van SPF, DKIM en DMARC, en levert daarbij uitleg van de protocollen en een mooie visualisatie.

Vroeger was er geen manier om het ontbreken van een mail-dienst op een domein expliciet aan te geven. Voor het afleveren van berichten werd door de verzender eerst naar een MX-record gevraagd en daarna een fallback gedaan naar de A/AAAA-records. Pas als op de (web-)server geen mail-ingang (SMTP op poort 25) werd gevonden, wist een verzender (pas na herhaaldelijk proberen en geruime tijd later!) dat het betreffende domein geen mail-dienst beschikbaar had.

RFC 7505 introduceerde een manier om expliciet in de DNS aan te geven dat een domein niet voor mail wordt gebruikt: het Null MX-record. Deze ziet er als volgt uit (let op de punt aan het eind):

domeinnaam.nl IN MX 0 .

Omdat deze mogelijkheid relatief nieuw is (de betreffende RFC werd in 2015 gepubliceerd), zijn er nog een heleboel domeinen zonder maildienst die geen Null MX-record hebben (op dit moment (april 2024) zijn bijna 50 duizend .nl-domeinen van een dergelijk record voorzien). Omwille van zowel de efficiëntie als de veiligheid, raden wij aan om deze domeinen wel van een dergelijk record te voorzien.

Bij een Null MX-record publiceer je bovendien een SPF-record waarin geen enkele server is geautoriseerd om namens dit domein berichten te verzenden:

domeinnaam.nl IN TXT "v=spf1 -all"

En een DMARC-record ingesteld op 'reject' en voorzien van een RUA-adres (uiteraard op een ander domein):

_dmarc.domeinnaam.nl IN TXT "v=DMARC1; p=reject; sp=reject;

adkim=s; aspf=s; rua=mailto:dmarc-reports@example.nl;"

Let op dat de ontvanger van de DMARC-rapportages op zijn domein wel eerst middels een DMARC-autorisatierecord toestemming moet geven voor aflevering van deze berichten:

domeinnaam.nl._report._dmarc.example.nl IN TXT "v=DMARC1;"

BIMI staat voor Brand Indicators for Message Identification. Dit beveiligingsmechanisme geeft organisaties – maar ook anderen – de mogelijkheid om aan ontvangende zijde hun logo te laten tonen bij geauthentiseerde mailberichten afkomstig van hun domeinnaam.

Mail-clients laten het betreffende logo alleen zien bij berichten die bij binnenkomst positief valideren voor DMARC. Google en Apple eisen voor BIMI bovendien dat de domeinnaamhouder middels een Verified Mark Certificate (VMC) aantoont dat hij inderdaad eigenaar is van het betreffende (geregistreerde) logo. In dat geval tonen zij het logo voorzien van een vinkje. Daarnaast nemen de grote mail-verwerkers ook de reputatie van het afzenderdomein nog mee in hun beoordeling [1].

Met al deze checks kan de ontvanger van een mailbericht ervan uitgaan dat het inderdaad verstuurd is door de organisatie die bij het logo+vinkje hoort.

Om BIMI te gebruiken, nemen domeinnaamhouders in hun DNS-zone een speciaal TXT-record op. Daarin geven zij aan waar hun logo en het bijbehorende Verified Mark Certificate (VMC) gevonden kunnen worden.

Aan de ontvangende zijde is de MX-gateway (of de laatste MTA in de mail-keten) verantwoordelijk voor alle veiligheidscontroles: BIMI-validatie vindt plaats gelijk na de SPF/DKIM/DMARC-validaties. Daar kijkt de MTA voor een binnengekomen bericht met positieve DMARC-validatie of er ook een BIMI-record is gepubliceerd. Uitgangspunt daarbij is het afzenderadres in de From-header, vandaar dat ook de alignment met het afzenderdomein in de envelope (SPF) en het signing domain (DKIM) in de (DMARC-)validatie worden meegenomen. Is er inderdaad een BIMI-record beschikbaar, dan haalt de MTA het aangegeven logo en VMC-certificaat op. Blijkt uit het certificaat dat het logo inderdaad bij het afzenderdomein hoort, dan levert dat een positieve validatie op.

De uitkomsten van de BIMI-validatie en (in geval van een positieve validatie) het logo zelf worden in de vorm van headers aan het bericht toegevoegd. De mail-client (MUA) gebruikt de informatie in deze headers vervolgens om al dan niet het logo+vinkje te tonen.

Een ontvangende MTA die BIMI ondersteunt, controleert eerst met behulp van DMARC de authenticiteit van een binnengekomen mail-bericht. Vervolgens wordt met behulp van het Verified Mark Certificate (VMC) gecontroleerd of het aangegeven logo inderdaad bij het afzenderdomein hoort [1]. Alleen als dit alles in orde is, zal de mail-client (MUA) bij het betreffende bericht ook het bijbehorende logo+vinkje tonen.

Op deze manier kan de ontvanger van een mailbericht ervan uitgaan dat het inderdaad verstuurd is door de organisatie die bij het getoonde logo hoort. Daarmee worden mail-spoofing, typosquatting en phishing door kwaadwillenden verder tegengegaan.

Voor organisaties is BIMI een manier om ontvangers van hun mail-berichten te overtuigen dat deze inderdaad afkomstig zijn van de aangegeven afzender. Daarnaast is het een manier om hun merk onder de aandacht te brengen.

BIMI is op dit moment (juli 2024) een Internet Draft en nog geen RFC. De specificatie [1] wordt ontwikkeld door de BIMI Group, waarin onder andere Google, Fastmail, Yahoo, Mailchimp, SendGrid en diverse mail-beveiligingsbedrijven deelnemen.

Aan clientzijde wordt BIMI nu ondersteund door Google (Gmail), Fastmail, Apple (Mail) en Yahoo (Mail). Microsoft (Exchange/Outlook) ondersteunt BIMI expliciet niet.

Aan afzender-zijde wordt BIMI in Nederland sinds kort ondersteund door de politie (waarvan het top-level domein .politie door SIDN beheerd wordt), en door PostNL, de Belastingdienst en de Rabobank. Voor de politie maakt de implementatie van BIMI onderdeel uit van een bredere strategie voor de implementatie van moderne internetstandaarden.

Uit een inventarisatie die Freddie Leeman in mei 2024 deed, bleek dat slechts 0,76 procent van de domeinen uit de top-1-miljoen een BIMI-record had gepubliceerd. Van die domeinen bood ongeveer een kwart ook een Verified Mark Certificate (VMC) aan.

Op deze Phishing Scorecard kun je zien hoe het staat met de adoptie van DKIM, SPF, DMARC en BIMI in de wereld.

BIMI bouwt voort op de mail-beveiligingsstandaard DMARC (en dus ook op de daaronder liggende standaarden SPF en DKIM). Dat betekent dat deze standaarden eerst volledig op je mail-domein geïmplementeerd moeten zijn alvorens je met BIMI aan de slag kunt. Let op dat de DMARC-policy bovendien op 'reject' of 'quarantine' moet staan.

We verwijzen je graag naar ons maturitymodel voor moderne internetstandaarden voor een overzicht van (onder andere) de mailbeveiligingsstandaarden en hun onderlinge relaties en afhankelijkheden. Op die laatste pagina vind je ook links naar onze uitgebreide, stapsgewijze handleidingen voor de implementatie van SPF, DKIM en DMARC in Exim en Postfix.

Is dit alles voor elkaar, dan begint de implementatie van BIMI [1] met de publicatie van je logo in SVG(Z) P/S vector-formaat [1, 2, 3] op een HTTPS-webserver. Hoewel een Verified Mark Certificate (VMC) vooralsnog geen vereiste is volgens de BIMI-specificatie, worden logo's zonder een dergelijk certificaat (self-asserted BIMI) op dit moment helemaal niet weergegeven door Gmail en Apple Mail. Dat betekent dat je voor de volledige ondersteuning van BIMI eerst je logo moet registreren en daar vervolgens een VMC voor moet aanvragen (certified BIMI).

Als laatste publiceer je een speciaal TXT-record in de zone voor je hoofddomein:

default._bimi IN TXT "v=BIMI1; l=https://example.nl/bimi/logo.svg; a=https://example.nl/bimi/vmc.pem;"

Heb je geen VMC, dan laat je de laatste link weg of leeg:

default._bimi IN TXT "v=BIMI1; l=https://example.nl/bimi/logo.svg; a=;"

Het 'default'-label refereert hier naar de selector (vergelijk DKIM). Daarmee kun je verschillende logo's voor verschillende (typen) afzenders specificeren. Daarvoor moet je wel aanpassingen doen op je uitgaande mail-server: voor een andere selector dan de default moet de server (of de mail-client) een (DKIM-ondertekende) header als volgt aan de uitgaande berichten toevoegen:

BIMI-Selector: v=BIMI1; s=<selector>

Daarnaast kun je BIMI-records ook op een subdomein publiceren. De validatie begint bij het volledige afzenderdomein en loopt zolang geen BIMI-record gevonden is terug tot aan het hoofddomein.

De BIMI Group heeft een tool online staan om je BIMI-configuratie te testen:

https://bimigroup.org/bimi-generator/

Een tweede – meer up-to-date – vind je hier:

https://www.uriports.com/tools?method=bimi

Zoals je kunt zien hebben wij zelf ook een (self-asserted) BIMI-configuratie opgezet voor het sidn.nl domein.

Het lijkt op dit moment nog wat vroeg om als kleinere mailverwerker zelf BIMI te implementeren. De BIMI Group heeft wel verschillende libraries beschikbaar gesteld, waaronder een Perl-module voor BIMI-validatie en een uitgebreide milter-module voor mail-authenticatie waar ook de BIMI-module deel van uitmaakt.

Het grootste bezwaar tegen BIMI zijn de kosten van Verified Mark Certificates (VMC's). Helemaal los van de registratie van je logo vragen de aangesloten VMC-leveranciers 1.300 tot 1.500 dollar per jaar voor de uitgifte van een certificaat [1]. Bovendien levert de jaarlijkse update van het VMC-certificaat niet alleen een extra beheerslast op, maar loop je ook het risico deze updates te vergeten.

Daarnaast concurreert het BIMI-logo (dat domein-specifiek is) op een oneigenlijke manier met de profielfoto (avatar) van de afzender (een individu). Je zou dat eventueel kunnen afvangen door elke afzender zijn eigen selector te geven, maar dat wordt wel heel bewerkelijk en beperkt zich tot self-asserted BIMI. Hetzelfde geldt bijvoorbeeld ook voor vinkjes en andere indicators voor end-to-end encryptie gebaseerd op OpenPGP en S/MIME.

Tenslotte wordt self-asserted BIMI op dit moment niet ondersteund door Gmail en Apple Mail: zij geven het logo (met vinkje) alleen weer als er ook een geldige VMC beschikbaar is. Een idee is om de vinkjes te reserveren voor certified BIMI en alleen het logo (zonder vinkje) te tonen voor self-asserted BIMI. Dat laatste zou dan een indicator zijn voor een geldige DMARC-validatie. De BIMI Group zelf lijkt echter in te zetten op een verdere beweging naar certified BIMI.

Zoals de naam al suggereert lijkt BIMI vooral gemaakt voor marketeers, brand managers en grote ondernemingen die "voldoende budget overhebben" voor een hogere deliverability van hun berichten en een grotere zichtbaarheid van hun merk.