Krypteret levering: TLS, MTA-STS og DANE

Modul 5: Omdømme og de store modtagere · Læsetid: 10 minutter

Læringsmål: Efter denne lektion kan du forklare hvordan mailservere krypterer indbyrdes, hvorfor det som standard ikke kan håndhæves, og hvad MTA-STS, TLS-RPT og DANE ændrer ved det. Du kan slå recordene op og læse dem.

Nøglebegreber: STARTTLS mellem servere, opportunistisk kryptering, downgrade-angreb, MTA-STS (RFC 8461), _mta-sts-record, policy-fil, modus testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls-record, DANE for SMTP (RFC 7672), TLSA-record, DNSSEC

To slags forbindelser

I lektion 1.4 handlede det om forbindelsen mellem dit mailprogram og mailserveren hos din udbyder: port 587 med STARTTLS, eller 465 med direkte TLS, med login. Der har du selv kontrollen. Dit program ved hvilken server det forventer, kontrollerer certifikatet og nægter at forbinde hvis noget ikke stemmer.

Denne lektion handler om næste trin: forbindelsen mellem den afsendende server og den modtagende server, på port 25. Den forløber anderledes.

Opportunistisk: kryptering når det kan lade sig gøre

Når en server afleverer mail, opretter den forbindelse til modtagerens MX. Efter EHLO tjekker den om den modtagende server tilbyder STARTTLS. Hvis ja, skifter den til en krypteret forbindelse. Hvis nej, afleverer den bare mailen ukrypteret.

Det kaldes opportunistisk kryptering: kryptering når det kan lade sig gøre, ellers ikke. Og som regel kontrollerer den afsendende server ikke certifikatet strengt. Et udløbet eller selvlavet certifikat er så ingen grund til at stoppe.

Hvorfor er det sådan? Fordi mail altid skal blive ved med at virke, også med gamle servere. En afsender kan ikke vide om en modtager bør have TLS. Det gør to angreb mulige:

1. Downgrade. Nogen der kan ændre trafikken undervejs, fjerner ordet STARTTLS fra modtagerens svar. Afsenderen tror der ikke er nogen kryptering og afleverer ukrypteret. Angriberen læser med.
2. Falsk MX. Nogen der kan forfalske DNS-svar, opgiver sin egen server som MX. Fordi certifikatet ikke bliver kontrolleret, bemærker afsenderen intet.

I dag krypterer næsten alle store mailservere, og Gmail kræver at afsendere bruger TLS (lektion 5.3). Men "som regel krypteret" er noget andet end "altid og med den rigtige server". Til det findes der to løsninger: MTA-STS og DANE. Begge indstilles af modtageren: du lader derved vide at mail til dit domæne altid skal krypteres, til en server med et gyldigt certifikat.

MTA-STS: policy via en webside

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) fungerer med to dele.

En TXT-record der siger at der findes en policy:

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

Og en policy-fil på et fast sted, via https med et gyldigt 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 smarte: en afsender husker policyen i hele max_age-perioden. En angriber der senere fjerner ordet STARTTLS eller opgiver en falsk MX, bliver da afsløret: policyen siger at kryptering er obligatorisk, og hvilke servere der er gyldige. Ved allerførste forbindelse (før policyen er kendt) beskytter MTA-STS ikke; det er den kendte svaghed.

Et rigtigt eksempel er gmail.com: TXT-recorden _mta-sts.gmail.com findes, og policy-filen på https://mta-sts.gmail.com/.well-known/mta-sts.txt står på mode: enforce.

TLS-RPT: rapporter om mislykket kryptering

Med MTA-STS på enforce kan mail blive hængende hvis der er noget galt med dit certifikat. Det vil du gerne vide. Til det findes TLS-RPT (RFC 8460):

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

Afsendere der understøtter TLS-RPT (blandt andre Google og Microsoft), sender så dagligt en rapport i JSON-format: hvor mange forbindelser der lykkedes og hvilke der mislykkedes, med årsagen (for eksempel et udløbet certifikat eller et navn der ikke står i policyen). Ligesom med DMARC-rapporter (lektion 4.5) kan du lade dem behandle af en rapporttjeneste.

Rækkefølge ved indførelse: først TLS-RPT, så MTA-STS på testing, et par uger med at læse rapporter, og først derefter enforce. Det ligner DMARC-rådgivningslinjen: først kigge, så stram op.

DANE: certifikatet i DNS'en, sikret med DNSSEC

DANE (DNS-based Authentication of Named Entities) griber det anderledes an. Du sætter en TLSA-record i DNS'en ved hver MX-server, med et fingeraftryk af certifikatet eller nøglen:

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

_25._tcp betyder: for SMTP på port 25. De tre tal angiver hvordan værdien skal læses. For mailservere er 3 1 1 mest brugt: "dette er SHA-256-fingeraftrykket af den offentlige nøgle for netop denne server". Også 2 1 1 forekommer: så står fingeraftrykket af et mellemliggende certifikat i den.

En afsender der understøtter DANE, ser TLSA-recorden, kræver kryptering og kontrollerer om serverens certifikat passer. Passer det ikke, afleverer den ikke.

Hvorfor er DANE sikker mod forfalskede DNS-svar? Fordi det kun virker med DNSSEC (DNS-kursus lektion 8.1). Uden en gyldig DNSSEC-kæde bliver TLSA-records ignoreret. Det er netop tærsklen: både dit domæne (for MX) og mailserverens zone skal være signeret.

DANE har ingen "første gang"-svaghed som MTA-STS, og det er meget udbredt i Holland og Tyskland. internet.nl tester for det. Microsoft understøtter DANE for indgående mail i Exchange Online. Også MX-serverne hos internet.nl har TLSA-records.

Faldgrube: udskifter du certifikatet på en mailserver med DANE med en ny nøgle, så skal TLSA-recorden ændres med det samme, og det skal ske forinden: først tilføje den nye record, vente til TTL'en er udløbet, så først tage den nye nøgle i brug. Ellers afviser DANE-afsendere din mail. Ved 3 1 1 spiller det kun en rolle hvis nøglen ændres, ikke ved hver fornyelse med samme nøgle.

MTA-STS eller DANE?

Du må gerne bruge dem side om side. RFC 8461 siger at en afsender der understøtter DANE, lader DANE gå forud hvis der findes gyldige TLSA-records.

Hvem ordner det?

Dette indstiller du for modtagende mail på dit domæne. Kører din mail hos et hostingfirma eller en maildienst, afhænger det af den part:

• DANE kan kun lade sig gøre hvis udbyderen publicerer TLSA-records for sine mailservere, og dit domæne har DNSSEC. Hos WebOké kan du for eksempel slå DANE til samme sted som DNSSEC (se internet.nl-artiklen nedenfor); hos andre udbydere fungerer det tilsvarende eller er det ordnet som standard.
• MTA-STS kan du nogle gange selv indstille, men så skal mta-sts.example.com være en hjemmeside med et gyldigt certifikat, og du skal kende MX-navnene hos din udbyder.
• TLS-RPT kan du altid selv sætte op: det er kun en TXT-record med en rapportadresse.

For din udgående mail behøver du ikke gøre noget: serveren hos din udbyder afgør om den respekterer MTA-STS og DANE hos modtagere.

Sammenfatning

• Mellem mailservere er TLS som standard opportunistisk: krypteret når det kan lade sig gøre, uden streng certifikatkontrol. Det gør downgrade og falsk MX mulige.
• MTA-STS: TXT _mta-sts plus policy-fil på https://mta-sts.<domæne>/.well-known/mta-sts.txt; modus testing eller enforce.
• TLS-RPT: TXT _smtp._tls med en rapportadresse, til daglige rapporter om mislykket kryptering.
• DANE: TLSA-record på _25._tcp.<mx-server>, virker kun med DNSSEC og beskytter også den første forbindelse.
• Indfør det som DMARC: først rapporter (TLS-RPT, testing), så stram op.

Quiz

Opgave

Opgave Z5.4: Slå MTA-STS, TLS-RPT og DANE op. Slå MTA-STS-recorden og TLS-RPT-recorden op hos gmail.com, åbn policy-filen og udfyld modusen (enforce, testing eller none). Slå derefter TLSA-recorden op på _25._tcp.<mx-server> hos en MX-server for internet.nl, og udfyld de første tre tal for en af recorderne. Valgfrit: de samme spørgsmål for dit eget domæne (der må svaret gerne være "ingen"). Programmet henter alt live og sammenligner.

Læs videre

Trinnene i disse artikler gælder for panelerne hos WebOké; hos andre udbydere fungerer det tilsvarende.

• Internet.nl-tjekliste: Opnå 100% med din hjemmeside og e-mail
• Hvad er DNSSEC?
• Gratis DNS-kursus 8.1: DNSSEC i almindeligt sprog
• internet.nl, test din e-mail (uafhængig test af STARTTLS, DANE og mere): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE for SMTP)