Krypterad leverans: TLS, MTA-STS och DANE

Modul 5: Rykte och de stora mottagarna · Lästid: 10 minuter

Lärandemål: Efter den här lektionen kan du förklara hur mailservrar krypterar sinsemellan, varför det inte är tvingande som standard, och vad MTA-STS, TLS-RPT och DANE ändrar på det. Du kan slå upp och läsa posterna.

Nyckelbegrepp: STARTTLS mellan servrar, opportunistisk kryptering, downgrade-attack, MTA-STS (RFC 8461), _mta-sts-post, policyfil, läge testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls-post, DANE för SMTP (RFC 7672), TLSA-post, DNSSEC

Två typer av anslutningar

I lektion 1.4 handlade det om anslutningen mellan ditt mejlprogram och mailservern hos din leverantör: port 587 med STARTTLS, eller 465 med direkt TLS, med inloggning. Där har du själv kontrollen. Ditt program vet vilken server det förväntar sig, kontrollerar certifikatet och vägrar ansluta om något inte stämmer.

Den här lektionen handlar om nästa steg: anslutningen mellan den sändande servern och den mottagande servern, på port 25. Den fungerar annorlunda.

Opportunistisk: kryptera om det går

När en server levererar mejl ansluter den till mottagarens MX. Efter EHLO kollar den om den mottagande servern erbjuder STARTTLS. Om ja, växlar den till en krypterad anslutning. Om nej, levereras mejlet helt enkelt okrypterat.

Det kallas opportunistisk kryptering: kryptera om det går, annars inte. Och oftast kontrollerar den sändande servern inte certifikatet strikt. Ett utgånget eller egensignerat certifikat är då ingen anledning att avbryta.

Varför så? Eftersom e-post alltid måste fortsätta fungera, även med gamla servrar. En avsändare kan inte veta om en mottagare förväntas ha TLS. Det gör två attacker möjliga:

1. Downgrade. Någon som kan ändra trafiken på vägen tar bort ordet STARTTLS ur mottagarens svar. Avsändaren tror att det inte finns någon kryptering och levererar okrypterat. Angriparen läser med.
2. Falsk MX. Någon som kan förfalska DNS-svar anger en egen server som MX. Eftersom certifikatet inte kontrolleras märker avsändaren inget.

Numera krypterar nästan alla stora mailservrar, och Gmail kräver att avsändare använder TLS (lektion 5.3). Men "oftast krypterat" är något annat än "alltid och med rätt server". För det finns två lösningar: MTA-STS och DANE. Båda ställs in av mottagaren: du meddelar att mejl till din domän alltid ska krypteras, till en server med ett giltigt certifikat.

MTA-STS: policy via en webbsida

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) fungerar med två delar.

En TXT-post som säger att det finns en policy:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Och en policyfil på en fast plats, via https med ett giltigt certifikat:

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

Det smarta: en avsändare kommer ihåg policyn under hela max_age. En angripare som senare tar bort STARTTLS-ordet eller anger en falsk MX avslöjas då: policyn säger att kryptering är obligatorisk och vilka servrar som är giltiga. Vid den allra första anslutningen (innan policyn är känd) skyddar MTA-STS inte; det är den kända svagheten.

Ett verkligt exempel är gmail.com: TXT-posten _mta-sts.gmail.com finns, och policyfilen på https://mta-sts.gmail.com/.well-known/mta-sts.txt har mode: enforce.

TLS-RPT: rapporter om misslyckad kryptering

Med MTA-STS på enforce kan mejl bli liggande i kö om något är fel med ditt certifikat. Du vill veta om det. Därför finns TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Avsändare som stöder TLS-RPT (bland annat Google och Microsoft) skickar då dagligen en rapport i JSON-format: hur många anslutningar som lyckades och vilka som misslyckades, med orsaken (till exempel ett utgånget certifikat eller ett namn som inte finns i policyn). Precis som med DMARC-rapporter (lektion 4.5) kan du låta en rapporttjänst bearbeta dem.

Ordning vid införande: först TLS-RPT, sedan MTA-STS på testing, läs rapporter i några veckor, och först därefter enforce. Det liknar DMARC-tillvägagångssättet: först observera, sedan skärpa.

DANE: certifikatet i DNS, säkrat med DNSSEC

DANE (DNS-based Authentication of Named Entities) gör det på ett annat sätt. Du lägger i DNS en TLSA-post för varje MX-server, med ett fingeravtryck av certifikatet eller nyckeln:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp betyder: för SMTP på port 25. De tre siffrorna anger hur värdet ska läsas. För mailservrar är 3 1 1 vanligast: "det här är SHA-256-fingeravtrycket av den publika nyckeln hos exakt den här servern". Även 2 1 1 förekommer: då innehåller det fingeravtrycket av ett mellanliggande certifikat.

En avsändare som stöder DANE ser TLSA-posten, kräver kryptering och kontrollerar att serverns certifikat matchar. Matchar det inte, levererar den inte.

Varför är DANE säkert mot förfalskade DNS-svar? Eftersom det bara fungerar med DNSSEC (DNS-kursen lektion 8.1). Utan en giltig DNSSEC-kedja ignoreras TLSA-poster. Det är samtidigt tröskeln: både din domän (för MX) och mailserverns zon måste vara signerade.

DANE har ingen "första gången"-svaghet som MTA-STS, och det används mycket i Nederländerna och Tyskland. internet.nl testar det. Microsoft stöder DANE för inkommande mejl i Exchange Online. Även internet.nls MX-servrar har TLSA-poster.

Fallgrop: byter du ut certifikatet på en mailserver med DANE mot en ny nyckel, måste TLSA-posten ändras samtidigt, och det i förväg: först läggs den nya posten till, vänta tills TTL har löpt ut, och först då tas den nya nyckeln i bruk. Annars vägrar DANE-avsändare ditt mejl. Vid 3 1 1 spelar det bara roll om nyckeln ändras, inte vid varje förnyelse med samma nyckel.

MTA-STS eller DANE?

Du får använda dem parallellt. RFC 8461 säger att en avsändare som stöder DANE låter DANE gå före om det finns giltiga TLSA-poster.

Vem ordnar detta?

Det här ställer du in för mottagande mejl på din domän. Körs din mejl hos ett hostingföretag eller en mejltjänst beror det på den parten:

• DANE går bara om leverantören publicerar TLSA-poster för sina mailservrar och din domän har DNSSEC. Hos WebOké kan du till exempel aktivera DANE på samma ställe som DNSSEC (se internet.nl-artikeln nedan); hos andra leverantörer fungerar det på liknande sätt eller är redan ordnat som standard.
• MTA-STS kan du ibland ställa in själv, men då måste mta-sts.example.com vara en webbplats med ett giltigt certifikat och du måste känna till leverantörens MX-namn.
• TLS-RPT kan du alltid ställa in själv: det är bara en TXT-post med en rapportadress.

För din utgående mejl behöver du inte göra något: din leverantörs server avgör om den respekterar mottagares MTA-STS och DANE.

Sammanfattning

• Mellan mailservrar är TLS som standard opportunistisk: krypterat om det går, utan strikt certifikatkontroll. Det gör downgrade och falsk MX möjliga.
• MTA-STS: TXT _mta-sts plus policyfil på https://mta-sts.<domän>/.well-known/mta-sts.txt; läge testing eller enforce.
• TLS-RPT: TXT _smtp._tls med en rapportadress, för dagliga rapporter om misslyckad kryptering.
• DANE: TLSA-post på _25._tcp.<mx-server>, fungerar bara med DNSSEC och skyddar även den första anslutningen.
• Inför stegvis som med DMARC: först rapporter (TLS-RPT, testing), sedan skärp.

Quiz

Uppgift

Uppgift Z5.4: Slå upp MTA-STS, TLS-RPT och DANE. Slå upp MTA-STS-posten och TLS-RPT-posten hos gmail.com, öppna policyfilen och fyll i läget (enforce, testing eller none). Slå därefter upp TLSA-posten på _25._tcp.<mx-server> hos en MX-server för internet.nl och fyll i de tre första siffrorna för en av posterna. Valfritt: samma frågor för din egen domän (där får svaret vara "ingen"). Programmet hämtar allt live och jämför.

Läs mer

Stegen i de här artiklarna gäller för WebOkés paneler; hos andra leverantörer fungerar det på liknande sätt.

• Internet.nl-checklista: nå 100% med din webbplats och e-post
• Vad är DNSSEC?
• Gratis DNS-kurs 8.1: DNSSEC i vanligt språk
• internet.nl, testa din e-post (oberoende test av STARTTLS, DANE med mera): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE för SMTP)