Kryptert levering: TLS, MTA-STS og DANE

Modul 5: Omdømme og de store mottakerne · Lesetid: 10 minutter

Læringsmål: Etter denne leksjonen kan du forklare hvordan mailservere krypterer innbyrdes, hvorfor det som standard ikke kan håndheves, og hva MTA-STS, TLS-RPT og DANE endrer på dette. Du kan slå opp og lese postene.

Nøkkelbegreper: STARTTLS mellom servere, opportunistisk kryptering, nedgraderingsangrep (downgrade), MTA-STS (RFC 8461), _mta-sts-post, policyfil, modus testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls-post, DANE for SMTP (RFC 7672), TLSA-post, DNSSEC

To typer forbindelser

I leksjon 1.4 handlet det om forbindelsen mellom e-postprogrammet ditt og mailserveren til leverandøren din: port 587 med STARTTLS, eller 465 med direkte TLS, med innlogging. Der har du selv kontrollen. Programmet ditt vet hvilken server det forventer, kontrollerer sertifikatet og nekter å koble til hvis noe ikke stemmer.

Denne leksjonen handler om neste steg: forbindelsen mellom den sendende serveren og den mottakende serveren, på port 25. Den fungerer annerledes.

Opportunistisk: krypter når det er mulig

Når en server leverer e-post, kobler den til MX-en til mottakeren. Etter EHLO sjekker den om den mottakende serveren tilbyr STARTTLS. Hvis ja, bytter den til en kryptert forbindelse. Hvis nei, leverer den e-posten ukryptert uten videre.

Dette kalles opportunistisk kryptering: krypter når det er mulig, ellers ikke. Og vanligvis kontrollerer den sendende serveren ikke sertifikatet strengt. Et utløpt eller selvsignert sertifikat er da ingen grunn til å stoppe.

Hvorfor er det slik? Fordi e-post alltid må fungere, også med gamle servere. En avsender kan ikke vite om en mottaker skal ha TLS. Det gjør to angrep mulig:

1. Nedgradering (downgrade). Noen som kan endre trafikken underveis, fjerner ordet STARTTLS fra svaret til mottakeren. Avsenderen tror det ikke finnes kryptering og leverer ukryptert. Angriperen leser med.
2. Falsk MX. Noen som kan forfalske DNS-svar, oppgir sin egen server som MX. Fordi sertifikatet ikke blir kontrollert, merker avsenderen ingenting.

I dag krypterer nesten alle store mailservere, og Gmail krever at avsendere bruker TLS (leksjon 5.3). Men "som regel kryptert" er noe annet enn "alltid og med riktig server". Derfor finnes det to løsninger: MTA-STS og DANE. Begge stilles inn av mottakeren: du gir dermed beskjed om at e-post til domenet ditt alltid må være kryptert, til en server med et gyldig sertifikat.

MTA-STS: policy via en nettside

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

En TXT-post som sier at det finnes en policy:

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

Og en policyfil på et fast sted, via https med et gyldig sertifikat:

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 avsender husker policyen i hele max_age-perioden. En angriper som senere fjerner ordet STARTTLS eller oppgir en falsk MX, blir da avslørt: policyen sier at kryptering er obligatorisk og hvilke servere som er gyldige. Ved den aller første forbindelsen (før policyen er kjent) beskytter ikke MTA-STS; det er den kjente svake siden.

Et ekte eksempel er gmail.com: TXT-posten _mta-sts.gmail.com finnes, og policyfilen på https://mta-sts.gmail.com/.well-known/mta-sts.txt har mode: enforce.

TLS-RPT: rapporter om mislykket kryptering

Med MTA-STS på enforce kan e-post bli stående hvis noe er galt med sertifikatet ditt. Det vil du vite om. Derfor finnes TLS-RPT (RFC 8460):

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

Avsendere som støtter TLS-RPT (blant annet Google og Microsoft), sender da daglig en rapport i JSON-format: hvor mange forbindelser som lyktes og hvilke som mislyktes, med årsak (for eksempel et utløpt sertifikat eller et navn som ikke står i policyen). Akkurat som med DMARC-rapporter (leksjon 4.5) kan du få disse behandlet av en rapporttjeneste.

Rekkefølge ved innføring: først TLS-RPT, deretter MTA-STS på testing, les rapporter i noen uker, og først deretter enforce. Dette ligner på den gradvise innføringen av DMARC: først se an, så stram til.

DANE: sertifikatet i DNS-en, sikret med DNSSEC

DANE (DNS-based Authentication of Named Entities) løser det annerledes. Du legger inn en TLSA-post i DNS-en for hver MX-server, med et fingeravtrykk av sertifikatet eller nøkkelen:

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

_25._tcp betyr: for SMTP på port 25. De tre tallene angir hvordan verdien skal leses. For mailservere er 3 1 1 mest brukt: "dette er SHA-256-fingeravtrykket av den offentlige nøkkelen til nettopp denne serveren". Også 2 1 1 forekommer: da står fingeravtrykket av et mellomsertifikat i posten.

En avsender som støtter DANE, ser TLSA-posten, krever kryptering og kontrollerer om sertifikatet til serveren stemmer. Stemmer det ikke, leverer den ikke.

Hvorfor er DANE sikkert mot forfalskede DNS-svar? Fordi det bare fungerer med DNSSEC (DNS-kurset, leksjon 8.1). Uten en gyldig DNSSEC-kjede blir TLSA-poster ignorert. Det er samtidig terskelen: både domenet ditt (for MX-en) og sonen til mailserveren må være signert.

DANE har ingen "første gang"-svakhet slik MTA-STS har, og det er mye brukt i Nederland og Tyskland. internet.nl tester på det. Microsoft støtter DANE for innkommende e-post i Exchange Online. Også MX-serverne til internet.nl har TLSA-poster.

Fallgruve: bytter du ut sertifikatet til en mailserver med DANE med en ny nøkkel, må TLSA-posten endres samtidig, og det på forhånd: først legge til den nye posten, vente til TTL-en har utløpt, deretter ta den nye nøkkelen i bruk. Ellers avviser DANE-avsendere e-posten din. Ved 3 1 1 gjelder dette bare når nøkkelen endres, ikke ved hver fornyelse med samme nøkkel.

MTA-STS eller DANE?

Du kan bruke dem begge samtidig. RFC 8461 sier at en avsender som støtter DANE, lar DANE gå foran hvis det finnes gyldige TLSA-poster.

Hvem ordner dette?

Dette stiller du inn for mottatt e-post på domenet ditt. Kjører e-posten din hos et hostingselskap eller en e-posttjeneste, avhenger det av den leverandøren:

• DANE er bare mulig hvis leverandøren publiserer TLSA-poster for mailserverne sine og domenet ditt har DNSSEC. Hos WebOké kan du for eksempel aktivere DANE på samme sted som DNSSEC (se internet.nl-artikkelen under); hos andre leverandører fungerer det på lignende måte eller er det allerede ordnet som standard.
• MTA-STS kan du noen ganger stille inn selv, men da må mta-sts.example.com være et nettsted med et gyldig sertifikat, og du må kjenne MX-navnene til leverandøren din.
• TLS-RPT kan du alltid stille inn selv: det er bare en TXT-post med en rapportadresse.

For utgående e-post trenger du ikke gjøre noe: serveren til leverandøren din bestemmer om den respekterer MTA-STS og DANE hos mottakere.

Oppsummering

• Mellom mailservere er TLS som standard opportunistisk: kryptert når det er mulig, uten streng sertifikatkontroll. Det gjør nedgradering og falsk MX mulig.
• MTA-STS: TXT _mta-sts pluss policyfil på https://mta-sts.<domene>/.well-known/mta-sts.txt; modus testing eller enforce.
• TLS-RPT: TXT _smtp._tls med en rapportadresse, for daglige rapporter om mislykket kryptering.
• DANE: TLSA-post på _25._tcp.<mx-server>, fungerer bare med DNSSEC og beskytter også den første forbindelsen.
• Innfør det som med DMARC: først rapporter (TLS-RPT, testing), så stram til.

Quiz

Oppgave

Oppgave Z5.4: Slå opp MTA-STS, TLS-RPT og DANE. Slå opp MTA-STS-posten og TLS-RPT-posten for gmail.com, åpne policyfilen og fyll inn modusen (enforce, testing eller none). Slå deretter opp TLSA-posten på _25._tcp.<mx-server> for en MX-server til internet.nl og fyll inn de tre første tallene i en av postene. Valgfritt: de samme spørsmålene for ditt eget domene (der kan svaret være "ingen"). Programmet henter alt live og sammenligner.

Les mer

Stegene i disse artiklene gjelder for kontrollpanelene til WebOké; hos andre leverandører fungerer det på lignende måte.

• Internet.nl-sjekkliste: Oppnå 100 % med nettsiden og e-posten din
• Hva er DNSSEC?
• Gratis DNS-kurs 8.1: DNSSEC på godt norsk
• internet.nl, test e-posten din (uavhengig test av STARTTLS, DANE og mer): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE for SMTP)