Module 5 · 5.4
Versleuteld afleveren: TLS, MTA-STS en DANE
Module 5: Reputatie en de grote ontvangers · Leestijd: 10 minuten
Leerdoel: Na deze les kun je uitleggen hoe mailservers onderling versleutelen, waarom dat standaard niet afdwingbaar is, en wat MTA-STS, TLS-RPT en DANE daaraan veranderen. Je kunt de records opzoeken en lezen.
Kernbegrippen: STARTTLS tussen servers, opportunistische versleuteling, downgrade-aanval, MTA-STS (RFC 8461), _mta-sts-record, beleidsbestand, modus testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls-record, DANE voor SMTP (RFC 7672), TLSA-record, DNSSEC
Twee soorten verbindingen
In les 1.4 ging het over de verbinding tussen jouw mailprogramma en de mailserver van je aanbieder: poort 587 met STARTTLS, of 465 met directe TLS, met inloggen. Daar heb je zelf de controle. Je programma weet welke server het verwacht, controleert het certificaat en weigert te verbinden als er iets niet klopt.
Deze les gaat over de stap daarna: de verbinding tussen de verzendende server en de ontvangende server, op poort 25. Die verloopt anders.
Opportunistisch: versleutelen als het kan
Als een server mail aflevert, maakt hij verbinding met de MX van de ontvanger. Na EHLO kijkt hij of de ontvangende server STARTTLS aanbiedt. Zo ja, dan schakelt hij over op een versleutelde verbinding. Zo nee, dan levert hij de mail gewoon onversleuteld af.
Dat heet opportunistische versleuteling: versleutelen als het kan, anders niet. En meestal controleert de verzendende server het certificaat niet streng. Een verlopen of zelfgemaakt certificaat is dan geen reden om te stoppen.
Waarom zo? Omdat mail altijd moet blijven werken, ook met oude servers. Een verzender kan niet weten of een ontvanger TLS hoort te hebben. Dat maakt twee aanvallen mogelijk:
- Downgrade. Iemand die het verkeer onderweg kan aanpassen, haalt het woord
STARTTLSuit het antwoord van de ontvanger. De verzender denkt dat er geen versleuteling is en levert onversleuteld af. De aanvaller leest mee. - Valse MX. Iemand die DNS-antwoorden kan vervalsen, geeft een eigen server op als MX. Omdat het certificaat niet wordt gecontroleerd, merkt de verzender niets.
Tegenwoordig versleutelen bijna alle grote mailservers, en Gmail eist van verzenders dat ze TLS gebruiken (les 5.3). Maar "meestal versleuteld" is iets anders dan "altijd en met de juiste server". Daarvoor zijn er twee oplossingen: MTA-STS en DANE. Allebei worden ze ingesteld door de ontvanger: je laat ermee weten dat mail naar jouw domein altijd versleuteld moet, bij een server met een geldig certificaat.
MTA-STS: beleid via een webpagina
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) werkt met twee onderdelen.
Een TXT-record dat zegt dat er een beleid is:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"En een beleidsbestand op een vaste plek, via https met een geldig certificaat:
https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800| Regel | Betekenis |
|---|---|
mode: enforce | Lever alleen af via TLS met een geldig certificaat bij een van de genoemde MX-servers. Lukt dat niet, dan niet afleveren (het blijft in de wachtrij) |
mode: testing | Lever af zoals altijd, maar meld problemen via TLS-RPT |
mode: none | Er is geen beleid (meer) |
mx: | De namen van de MX-servers die het certificaat moeten dragen; een *. aan het begin mag |
max_age: | Hoe lang (in seconden) een verzender het beleid mag onthouden |
id= in het TXT-record | Een versienummer. Pas je het beleid aan, verander dan ook de id, zodat verzenders het bestand opnieuw ophalen |
Het slimme: een verzender onthoudt het beleid voor de duur van max_age. Een aanvaller die later het STARTTLS-woord weghaalt of een valse MX geeft, valt dan door de mand: het beleid zegt dat versleuteling verplicht is en welke servers geldig zijn. Bij de allereerste verbinding (voordat het beleid bekend is) beschermt MTA-STS niet; dat is de bekende zwakke plek.
Een echt voorbeeld is gmail.com: het TXT-record _mta-sts.gmail.com bestaat, en het beleidsbestand op https://mta-sts.gmail.com/.well-known/mta-sts.txt staat op mode: enforce.
TLS-RPT: rapporten over mislukte versleuteling
Met MTA-STS op enforce kan mail blijven hangen als er iets mis is met je certificaat. Je wilt dat weten. Daarvoor is TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"Verzenders die TLS-RPT ondersteunen (onder andere Google en Microsoft), sturen dan dagelijks een rapport in JSON-formaat: hoeveel verbindingen gelukt zijn en welke mislukt, met de reden (bijvoorbeeld een verlopen certificaat of een naam die niet in het beleid staat). Net als bij DMARC-rapporten (les 4.5) kun je die laten verwerken door een rapportdienst.
Volgorde bij invoeren: eerst TLS-RPT, dan MTA-STS op testing, een paar weken rapporten lezen, en pas daarna enforce. Dat lijkt op de DMARC-advieslijn: eerst kijken, dan streng.
DANE: het certificaat in de DNS, beveiligd met DNSSEC
DANE (DNS-based Authentication of Named Entities) pakt het anders aan. Je zet in de DNS een TLSA-record bij elke MX-server, met een vingerafdruk van het certificaat of de sleutel:
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp betekent: voor SMTP op poort 25. De drie getallen zeggen hoe de waarde gelezen moet worden. Voor mailservers is 3 1 1 het meest gebruikt: "dit is de SHA-256-vingerafdruk van de publieke sleutel van precies deze server". Ook 2 1 1 komt voor: dan staat de vingerafdruk van een tussencertificaat erin.
Een verzender die DANE ondersteunt, ziet het TLSA-record, eist versleuteling en controleert of het certificaat van de server past. Past het niet, dan levert hij niet af.
Waarom is DANE veilig tegen vervalste DNS-antwoorden? Omdat het alleen werkt met DNSSEC (DNS-cursus les 8.1). Zonder geldige DNSSEC-keten worden TLSA-records genegeerd. Dat is meteen de drempel: zowel je domein (voor de MX) als de zone van de mailserver moeten ondertekend zijn.
DANE heeft geen "eerste keer"-zwakte zoals MTA-STS, en het is in Nederland en Duitsland veel gebruikt. internet.nl test erop. Microsoft ondersteunt DANE voor inkomende mail in Exchange Online. Ook de MX-servers van internet.nl hebben TLSA-records.
Valkuil: vervang je het certificaat van een mailserver met DANE door een nieuwe sleutel, dan moet het TLSA-record mee veranderen, en wel vooraf: eerst het nieuwe record erbij, wachten tot de TTL verstreken is, dan pas de nieuwe sleutel in gebruik. Anders weigeren DANE-verzenders je mail. Bij 3 1 1 speelt dat alleen als de sleutel verandert, niet bij elke verlenging met dezelfde sleutel.
MTA-STS of DANE?
| MTA-STS | DANE | |
|---|---|---|
| Heeft DNSSEC nodig | Nee | Ja |
| Waar staat het | TXT-record plus beleidsbestand op een website | TLSA-record per MX-server |
| Beschermt de eerste verbinding | Nee | Ja |
| Onderhoud | Website en certificaat voor mta-sts. bijhouden | TLSA bijwerken bij een nieuwe sleutel |
Je mag ze naast elkaar gebruiken. RFC 8461 zegt dat een verzender die DANE ondersteunt, DANE voor laat gaan als er geldige TLSA-records zijn.
Wie regelt dit?
Dit stel je in voor ontvangende mail op je domein. Draait je mail bij een hostingbedrijf of maildienst, dan hangt het van die partij af:
- DANE kan alleen als de aanbieder TLSA-records publiceert voor zijn mailservers en jouw domein DNSSEC heeft. Bij WebOké kun je DANE bijvoorbeeld op dezelfde plek aanzetten als DNSSEC (zie het internet.nl-artikel hieronder); bij andere aanbieders werkt het vergelijkbaar of is het standaard geregeld.
- MTA-STS kun je soms zelf instellen, maar dan moet
mta-sts.example.comeen website met een geldig certificaat zijn en moet je de MX-namen van je aanbieder kennen. - TLS-RPT kun je altijd zelf zetten: het is alleen een TXT-record met een rapportadres.
Voor je uitgaande mail hoef je niets te doen: de server van je aanbieder bepaalt of hij MTA-STS en DANE van ontvangers respecteert.
Samenvatting
- Tussen mailservers is TLS standaard opportunistisch: versleuteld als het kan, zonder strenge certificaatcontrole. Dat maakt downgrade en valse MX mogelijk.
- MTA-STS: TXT
_mta-stsplus beleidsbestand ophttps://mta-sts.<domein>/.well-known/mta-sts.txt; modustestingofenforce. - TLS-RPT: TXT
_smtp._tlsmet een rapportadres, voor dagelijkse rapporten over mislukte versleuteling. - DANE: TLSA-record op
_25._tcp.<mx-server>, werkt alleen met DNSSEC en beschermt ook de eerste verbinding. - Voer in zoals DMARC: eerst rapporten (TLS-RPT,
testing), dan streng.
Quiz
Opdracht
Opdracht Z5.4: MTA-STS, TLS-RPT en DANE opzoeken. Zoek bij gmail.com het MTA-STS-record en het TLS-RPT-record op, open het beleidsbestand en vul de modus in (enforce, testing of none). Zoek daarna bij een MX-server van internet.nl het TLSA-record op _25._tcp.<mx-server> en vul de eerste drie getallen in van een van de records. Optioneel: dezelfde vragen voor je eigen domein (daar mag het antwoord "geen" zijn). Het programma vraagt alles live op en vergelijkt.
Verder lezen
De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.
- Internet.nl-checklist: 100% halen met je website en e-mail
- Wat is DNSSEC?
- Gratis DNS-cursus 8.1: DNSSEC in gewone taal
- internet.nl, test je e-mail (onafhankelijke test van STARTTLS, DANE en meer): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE voor SMTP)