MTA-STS och TLS-RPT: tvinga fram TLS för inkommande e-post

Varför räcker inte STARTTLS?

E-postservrar krypterar SMTP med STARTTLS, men bara opportunistiskt. Den sändande servern frågar den mottagande om den stöder TLS och faller tillbaka till klartext om svaret är nej. Den godtar dessutom nästan vilket certifikat som helst, eftersom det traditionellt inte har funnits något sätt att veta vilket certifikat som är det rätta.

En angripare på nätverksvägen kan ta bort STARTTLS ur serverns svar, en så kallad nedgraderingsattack (stripping), och läsa e-posten i klartext. En angripare som kan manipulera DNS kan också peka om er MX-post till sin egen server. Utan en policy har avsändaren ingen anledning att behandla något av fallen som ett fel.

Vad gör MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) låter en domän publicera en policy som säger: leverera bara till de här MX-värdarna, bara över TLS och bara om certifikatet är giltigt för MX-värdens namn. Sändande servrar med stöd för MTA-STS hämtar policyn över HTTPS och cachar den.

När policyn är i läget enforce levererar en avsändare med stöd inte över klartext eller till en server med ogiltigt certifikat. Den försöker igen och returnerar till slut meddelandet som olevererbart. Eftersom policyn hämtas över HTTPS med ett giltigt certifikat kan en angripare inte förfalska den genom att bara manipulera DNS.

MTA-STS skyddar e-post som andra skickar till er domän. Om er utgående e-post skyddas beror på mottagardomänernas policyer.

Hur sätter jag upp DNS-posten _mta-sts och policyfilen?

MTA-STS består av två delar. Den första är en TXT-post på _mta-sts under er domän. Den talar om för avsändare att det finns en policy och ger den ett id:

_mta-sts.example.com. TXT "v=STSv1; id=20261110T120000"

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: *.mail.example.net
max_age: 604800

Den andra delen är policyfilen, som publiceras på https://mta-sts.example.com/.well-known/mta-sts.txt som text/plain. version är alltid STSv1. Varje mx-rad anger en MX-värd som får ta emot er e-post, och ett jokertecken täcker en etikett längst till vänster. max_age anger i sekunder hur länge avsändare får cacha policyn, högst 31557600 (ungefär ett år). En vecka, 604800, är en vanlig startpunkt.

Värden mta-sts måste ha ett giltigt, publikt betrott certifikat för mta-sts.example.com och svara utan omdirigeringar. Varje MX-värd måste visa ett certifikat som är giltigt för MX-värdens namn och som leder till en betrodd certifikatutfärdare. Självsignerade eller utgångna certifikat underkänns i läget enforce.

När ni ändrar policyfilen ska ni också ändra id i TXT-posten. Avsändare hämtar policyn igen först när id ändras eller deras cachade kopia går ut. Datum och tid fungerar bra som id. Det får vara högst 32 bokstäver och siffror.

Vad är skillnaden mellan testing, enforce och none?

• mode: testing betyder att avsändare kontrollerar policyn och rapporterar fel via TLS-RPT, men levererar e-posten ändå.
• mode: enforce betyder att avsändare vägrar leverera om TLS eller certifikatkontrollen misslyckas, eller om MX-värden inte finns med i policyn.
• mode: none säger åt avsändare att sluta tillämpa en policy de har cachat. Använd det när ni vill ta bort MTA-STS, och låt det ligga kvar tills den gamla max_age har löpt ut.

Vad är TLS-RPT och vad visar rapporterna?

TLS-RPT (SMTP TLS Reporting, RFC 8460) är en TXT-post på _smtp._tls under er domän. Den talar om för sändande servrar vart de ska rapportera resultatet av sina TLS-anslutningar till er:

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

Avsändare med stöd för TLS-RPT skickar en komprimerad JSON-rapport, oftast en gång per dygn. Den visar vilken policy de tillämpade, hur många sessioner som lyckades, hur många som misslyckades och varför. Feltyperna omfattar bland annat certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure och sts-policy-fetch-error.

TLS-RPT är användbart på egen hand, även utan MTA-STS. Det visar om avsändare når era MX-värdar över TLS och om era certifikat godkänns. DMARC Vision bevakar TLS-rapporter tillsammans med DMARC-rapporter.

Hur inför jag MTA-STS på ett säkert sätt?

1. Publicera en TLS-RPT-post och läs rapporterna i en eller två veckor. Åtgärda de certifikat- eller STARTTLS-problem de visar.
2. Sätt upp värden mta-sts med ett giltigt certifikat, publicera policyfilen med mode: testing och lägg till TXT-posten _mta-sts.
3. Följ TLS-RPT-rapporterna för policyfel. Kontrollera att varje MX-värd finns med i policyn och att dess certifikat stämmer.
4. När rapporterna inte visar några oväntade fel, ändra policyn till mode: enforce och uppdatera id.
5. Höj max_age när enforce har fungerat utan problem och fortsätt följa rapporterna. Kom ihåg att uppdatera policyn och id innan ni byter MX-värdar eller e-postleverantör.

Hur förhåller sig MTA-STS till DANE?

DANE för SMTP (RFC 7672) löser samma problem på ett annat sätt. Där publiceras TLSA-poster bredvid varje MX-värd, som talar om för avsändare vilket certifikat eller vilken nyckel de ska förvänta sig. DANE kräver DNSSEC i zonerna där era MX-värdar finns, och avsändaren måste validera DNSSEC.

MTA-STS kräver inte DNSSEC utan bygger i stället på webbens certifikatsystem. De två kan användas tillsammans. En avsändare som stöder båda får inte låta MTA-STS åsidosätta en misslyckad DANE-kontroll.