bloghoved sidsel jensen

Fremtidens mailstandarder: DANE, MTA-STS, TLS Reporting og OpenARC

De fleste af jer kender allerede SPF, DKIM og DMARC - men nu er der nye børn i klassen - som bygger ovenpå de eksisterende standarder på mailområdet og de er værd at holde sig ajour med, ihvertfald hvis man er en af dem, som konsekvent efterspørger mere sikkerhed omkring e-mail transport.

Der er hele 4 “boblere” på hit-listen:

SMTP er en “gammel” protokol (1982 - nærmest en dinosaur set med internet-øjne) og problemet er i sin enkelthed at mailserverne er nød til at blive enige om sikkerheden via signallering i protokollen. Den modtagende side kan ikke kommunikere sin krypteringspolitik “up-front” og afsendersiden kan ikke udlede krypteringspolitikken, den er nød til at “gætte”. Denne side har en fin beskrivelse af problematikken.

I et forsøg på at fixe problemet blev STARTTLS skabt - STARTTLS tager en eksisterende usikker forbindelse og opgraderer den til en sikker forbindelse ved brug af SSL/TLS. Man kalder det også for oppotunistisk TLS udfra en devise om at lidt kryptering er bedre end ingen kryptering. Men STARTTLS er sårbart overfor MiTM angreb - specifikt SCRIPTLS angreb som stripper STARTTLS kommandoen væk og derved tvinger serverne til at tale sammen ukrypteret. For at løse det problem blev DANE skabt.

SMTP DANE

  • DANE står for “Opportunistic DNS-Based Authentication of Named Entities” og har altså ikke noget med Danmark eller danskere at gøre ;-)
  • DANE er en godkendt IETF standard og har været det siden 2015.
  • DANE benytter DNSSEC.
  • DANE skal understøttes både på dine udgående og indgående mailservere.
  • DANE binder X.509 certifikater til DNS navne ved brug af DNSSEC (Domain Name System Security Extensions). Formålet med DANE er at gøre krypteret mail-levering til normen.
  • Postfix og Exim uderstøtter selvfølgelig DANE. Det samme gør Halon.

I Tyskland har standarden nu 50% adoption rate og i Holland kræver den hollandske regering at alle offentlige myndigheder benytter standarden. Den er på deres “comply or explain” liste. Det hollandske National Cyber Security Centre har lavet en rigtig fin vejledning omkring STARTTLS og DANE (hvorfor har vi ikke tilsvarende fornuftige vejledninger i NC3 i Danmark?)

DANE er dog stadig kun opportunistisk - så hvis afsender og modtager ikke kan blive enige, så er afsendersiden nød til at drosle sin sikkerhed ned - udfra den gamle mail-devise om at usikker levering er bedre end ingen levering.

For at få DANE til at virke skal du lave 2 DNS records - en DNSSEC TLSA record og en CNAME record i formattet:

_<port_number>._tcp.<mailserver>.
 
example.com.                IN MX 0 mx1.example.com.
example.com.                IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c149a...

TLSA recorden indeholder enten det fulde certifikat eller en hash som kan verificeres. Skal du have hjælp til at generere din TLSA record kan man med fordel bruge Shumon Huque's værktøj - vælg linket "DNS TLSA Record Generator".

Den anden udfordring med DANE er, at folk har en tendens til virkelig at fubar'e deres DNSSEC konfigurationer. Det kan være nødvendigt at lave en DANE bypass-liste til at håndtere disse domæner.

Patrick Koetter og venner har lavet et rigtigt fint site til at validere DANE SMTP.

MTA-STS

MTA-STS går skridtet videre end DANE og sikrer at man altid leverer krypteret - deraf navnet strict-transport security. Mange kalder dog MTA-STS for “DANE lite” og er en mulighed for at få højere sikkerhed uden brug af DNSSEC hvis man enten ikke kan eller vil bruge DNSSEC.

MTA-STS er afhængig af både en DNS TXT record og en json policy på en webside. TXT recorden skal indeholde et MTA-STS versions nummer (ligesom SPF og DMARC har det) og et id, som blot et en unik identifier.

Json policy filen skal ligge på https://mta-sts.example.com/.well-known/mta-sts.json

Et eksempel på en policy fil kan være :

                         version: STSv1
                         mode: enforce
                         mx: mail.example.com
                         mx: .example.net
                         mx: backupmx.example.com
                         max_age: 123456

Hvor mode kan være enforce, report eller none. Versions-feltet svarer til det angivne i DNS TXT recorden. MX-felterne svarer til dine DNS MX records og max-age er et TTL felt.

En well-behaved mailserver forventes selvfølgelig at cache policy oplysningerne.

Fraudmarc har lavet et udemærket domain policy checker tool. Man kan også bruge dette check-tool.

Google er en af de største backere af standarden og har selvfølgelig allerede implementeret den på gmail.com. Følgende mail-udbydere understøtter MTA-STS idag: gmail.com, yahoo.com, comcast.net, mail.com, web.de og gmx.com

Umiddelbart virker det som om at DANE er mest udbredt i Europa og MTA-STS er mest udbredt i USA. Er man mailprovider, bør man overveje om ikke det giver mest mening at implementerer begge standarder.

SMTP TLS Reporting

Hvad så med alle fejl-scenarierne? De udløbne certifikater (en klassisker), servere der ikke svarer, MITM attacks eller certifikater der ikke validerer imod Root-CA? Det er her TLS Reporting standarden kommer ind i billedet. Der findes to måder at sende fejl-rapporter på - enten via SMTP eller via HTTPS. Igen kræver det at man laver en TXT record i sin DNS opsætning:

Rapporter med MAILTO:

            _smtp-tlsrpt.example.com. IN TXT \
            "v=TLSRPTv1;rua=mailto:reports@example.com"

Rapporter med HTTPS:

           _smtp-tlsrpt.example.com. IN TXT \
           "v=TLSRPTv1; \
           rua=https://reporting.example.com/v1/tlsrpt"

Rapporten sendes i JSON format til den i TXT recorden definerede mailaddresse eller webside og der er allerede en række indbyggede DANE- og MTA-STS relaterede policy fejlgrunde som kan angives i rapporten f.eks. tlsa-invalid eller sts-policy-invalid.

Et eksempel på JSON rapport formattet:

OpenARC

ARC står for “Authenticated Received Chain”.

ARC er en standard, der er sat i verden for at håndtere de tilfælde hvor SPF og DKIM fejler hvis f.eks. en mailmodtager forwarder en mail eller hvis modtageren er en mailingliste. Hvis DMARC policien f.eks. er sat til p=reject, kan helt valide mailbeskeder fejle i valideringen hos den endelige modtager og dermed bliver de ikke leveret. ARC benytter sig af en række headers, der nemt kan checkes hos den endelige modtager. Med implementering af ARC, letter man også sin DMARC implementering, da det vil være langt lettere at gå fra p=quarantine til p=reject uden at bekymre sig om fejlede forwards. En række af de store mailproviders som f.eks. Google og AOL er allerede begyndt at benytte ARC headers for at teste standarden.

ARC håndteringen på den modtagende mailserver gemmer resultaterne af SPF, DKIM og DMARC valideringen og tilføjer dem som en ny ARC-Authentication-Results (AAR) header til mailen. Den sørger også for at signe message-body og tilføje signaturen til en ARC-Message-Signature (AMS) header. Afslutningsvis signer den udvalgte header-elementer af mailen så som TO: FROM: og Subject: + de to andre ARC-headers og placerer disse i en ARC-Seal (AS) header. Den offentlige nøgle, der bruges til at verificerer disse signaturer hentes på modtagersiden fra en DNS TXT RR record tilsvarende den der bruges til DKIM. Ligesom i DKIM bruges signaturerne til at verificerer identiteten af afsenderen/forwarderen eller mailingliste-serveren.

Foto: Sidsel Jensen

ARC understøttelse er allerede implementeret i mailman fra pkg 3.1+ og OpenARC milter understøttes i Postfix. ARC kan implementeres uafhængigt af DANE og MTA-STS, men det kræver at man som minimum har velfungerende DKIM og DMARC opsætninger. ARC er ikke en perfekt løsning, da ondsindede mellemled har en mulighed for at ændre eller helt droppe eksisterende ARC headers. Men det er et reelt alternativ til f.eks. SPF-SRS, som heller ikke kan siges at være en perfekt løsning - og der bliver også lidt meget lappeløsning over de her standarder hen af vejen.

Du kan læse mere om ARC specifikationen her.

Så ....nu er det bare et spørgsmål om at komme hjem og implementere - sæt igang! ;-)

P.S. Er man en af dem, der sidder (u)tålmodigt og venter på true-end-to-end-kryptering med PGP eller S/MIME så vil jeg foreslå at man istedet hopper ind på https://tutanota.com/da/ eller https://protonmail.com/

Kommentarer (14)
Christian Schmidt

Hvordan kan MTA-STS betegnes som et skridt videre end DANE. Er det ikke omvendt?

MTA-STS er sårbar over for man-in-the-middle-angreb. Da der ikke bruges DNSSEC, kan en mellemmand forhindre opslag af den relevante TXT-record, lige så vel som han kan strippe STARTTLS fra SMTP-strømmen. Problemet begrænses dog af, at TXT-recorden bliver cachet hos afsender, når man én gang har fået fat på den. Men første gang du sender til en ny afsender, er du sårbar.

Derudover er DANE vel lige så strict som MTA-STS. Afsenderserveren kan vel bare undlade at sende mailen af sted, hvis ikke modtagerserveren understøtter STARTTLS med det certifikat, der er angivet i DNS.

Eller hvad har jeg overset?

Sidsel Jensen Blogger

Det scenarie du beskriver er faktisk beskrevet i RFC'en under Security Considerations (side 14): https://tools.ietf.org/html/draft-ietf-uta-mta-sts-10#page-14 - og en kæmpe ulempe i den måde STARTTLS fungerer på :-(

Både DANE og MTA-STS har hver deres fordele og ulempler - spørgsmålet er vel om man så sværger mest til en DNSSEC løsning (yeah!) eller en CA-baseret løsning...

Torben Mogensen Blogger

Det er et tilbagevendende problem, at store vedhæftninger til mails kan få breve til at forsvinde ud i det blå uden fejlbeskeder. Det er årsagen til, at man i stedet ofte sender et link til en fil på DropBox eller bruger en tjeneste såsom BlueWhale.

Men det er blot symptombehandling -- email bør som udgangspunkt ikke have nogen øvre grænse for størrelsen af vedhæftede filer (eller den bør i hvert fald være større end tilfældet er nu, hvor selv et par MB kan få en mail til at forsvinde).

Løser nogen af de nye mailstandarder det problem, eller forholder de sig kun til kryptering?

Lasse Mølgaard

... email bør som udgangspunkt ikke have nogen øvre grænse for størrelsen af vedhæftede filer (eller den bør i hvert fald være større end tilfældet er nu, hvor selv et par MB kan få en mail til at forsvinde).

Jeg er helt enig med at standard øvre grænse skal op.

Årsagen er enkelt: Hvis man vil sende et enkelt billede fra f.eks. ens mobiltelefon til en mailadresse, så kan mailen hurtigt blive afvist, hvis man har ikke skaleret billedet ned.

Min indre mailadministrator stemme siger dog at grænsen skal ikke væk - ud fra en betragtningen om hvad er fair use, når folk sender og modtager filer via e-mail.

Jeg vil selv lave indivuduel quota styrring på størrelsen af email, hvor standarden er omkring 50 MB.

Hvis der er behov for at kunne modtage større emails, vil jeg klare dette ved at ændre maks størrelse for den pågældende mail adresse på et case-by-case basis.

Hvis man er hjemmevant i Linux verdenen, så er dette eksempel relativt trivielt, når man bruger Postfix som mailserver, som er koblet op imod en database.

Jeg har dog ikke prøvet det på entreprise skala, men umiddelbart burde grundidéen stadigvæk være den samme.

Det som komplicere ting er at den bagvedliggende database, skal sikkert caches på en-eller-anden måde på grund af performance hensyn.

Troels Henriksen

For mig er en af emails store styrker at decentralisering er indbygget. Det er naturligvis også en af årsagerne til at det fra et teknisk standpunkt er noget frygteligt rod, så det er ikke en afvejning der er nem at udføre.

Jeg er ikke selv professionel systemadministrator, blot en almindelig datalog, men driver alligevel min egen mailserver - dels for sørge for at jeg ikke ruster fuldstændigt, men også fordi jeg (så vidt muligt) gerne vil holde mig fri af de store organisationer. Jeg synes allerede nu at det er hårdt arbejde at holde sig opdateret på de forskellige tilvalgs-teknologier der skal aktiveres og opsættes for at min server ser pålidelig ud for andre, og det ser ud til at det kun bliver mere indviklet i fremtiden. Jeg finder det især vanskeligt, at hvis opsætningen er forkert (eller bliver det - f.eks. hvis et af de forskellige certifikater udløver), så er det ikke en støjende fejl som jeg hurtigt opdager, men har blot blot at den post jeg sender bliver kategoriseret som spam. Der kan gå lang tid før jeg opdager at noget er los.

Er der ikke en risiko for at email bliver mere centraliseret, når opsætning og vedligeholdelse kræver så mange specialierede kundskaber?

Sidsel Jensen Blogger

De nye standarder har ikke noget at gøre med størrelsen på vedhæftede filer.

Det er normalt en setting i Postfix, som nemt kan forsøges for at sætte den højere.

Der er op til den enkelte mail-administrator at sætte en for virksomheden passende grænse. Serveren skal helst ikke gå ned når nogen sender en 200MB video. Det der koster (CPU mæssigt) på mailserver siden er typisk vira-scan af store filer. Har man travl mailserver - kan det godt dreje sig om ret mange store filer...og deraf belastning af serveren.

Der er faktisk en SMTP enhanced status code RFC3463 til at håndterer fejlmeddelelser om en for stor vedhæftning - meeeen det er ikke alle mailservere der håndterer det lige pænt og deraf kan fejlmeddelelser om dette godt gå tabt.

Snakker vi Windows/Exchange/Outlook - så er der er default size på 20MB indbygget i Outlook klienten som man skal ind og ændre på i sine registry settings...på trods af at Exchange serveren default har 25MB....hvorimod Office365 understøtter f.eks. op til 150MB.

Bo Simonsen

Er der ikke en risiko for at email bliver mere centraliseret, når opsætning og vedligeholdelse kræver så mange specialierede kundskaber?

Jeg har præcis samme oplevelse som dig. Jeg har sat både SPF, DKIM og DMARC op på mit domæne og alligevel ryger mails til hotmail.com i Microsofts spamfilter uden jeg kan gennemskue hvorfor. Jeg er ret sikker på de fleste vil bruge en weekend (som privatperson) på at lave et sådan setup, og så hjælper det alligevel ikke alle steder. Jeg syntes stadigvæk, det er utroligt vigtigt at det stadig er muligt at drive en privat e-mail server uden du er tvunget til at bruge alle mulige underlige teknologier.

Lasse Mølgaard

Jeg har præcis samme oplevelse som dig. Jeg har sat både SPF, DKIM og DMARC op på mit domæne og alligevel ryger mails til hotmail.com i Microsofts spamfilter uden jeg kan gennemskue hvorfor.

Hvis dit issue er det samme som mit, så kan det sagtens være at din mailserver bruger en forkert signatur.

Uanset hvad har jeg fundet ud af "Unlock the inbox" har en meget nyttig test funktion.

Man sender en mail til deres test e-mail konto, hvorefter din mailserver bliver bombarderet i en 2-3 minutter med diverse forespørgsler.

Bagefter får du en mail med rapport med alle de ting, der skal rettes. Den tjekker naturligvis om din spf, dkim og dmarc indstillinger er korrekte.

Sidste gang jeg kørte testen fik jeg kun en advarsel, fordi min mailserver var ikke sat op til at modtage mails via submission.

Der er dog en hel del af testene, som den springer over, hvis man ikke betaler for testen, men det er i et prisleje, hvor jeg var villig til at betale.

Christian Schmidt

Jeg har nu publiceret en MTA-STS-policy for mit private e-maildomæne. Et par observationer:

I den seneste udgave af standarden er man gået væk fra at bruge JSON. Filen skal i stedet hedde /.well-known/mta-sts.txt, ikke /.well-known/mta-sts.json. I en overgangsperiode kan man have begge filer liggende.

Opsætning er ret omstændeligt, idet man skal have en webserver kørende på https://mta-sts.eksempel.dk for alle de domæner, man ønsker at modtage post på. Dvs. hvis man hoster mail for mange domæner, skal man have udstedt en masse HTTPS-certifikater. Dem kan man få gratis nu om stunder, men det virker unødigt bøvlet.

Alternativt skal din mailudbyder (fx G Suite aka Google Apps) gøre det for dig. Det havde været smart, om man direkte i TXT-recorden kunne angive en anden HTTPS-server. Men det introducerer muligvis en sikkerhedsbrist, jeg ikke lige kan gennemskue.

Christian Schmidt

Men det introducerer muligvis en sikkerhedsbrist, jeg ikke lige kan gennemskue.


For at besvare mit eget spørgsmål: Der skal udstedes et certifikat for selve maildomænet (dvs. ikke blot MX-serveren), for ellers er der ikke nogen digital signering af politikken, hvilket er en forudsætning for at undgå, at uvedkommende laver cache poisoning ved at forfalske en DNS-record, der så bliver hængende i mailafsenderens cache.

Endnu en observation:
MTA-STS er mest relevant for maildomæner, der modtager meget post. Det er bl.a. Google, Microsoft og Yahoo, der står bag standarden, og det passer fint ind i deres verdensbillede, idet alle mailservere i verden hurtigt får cachet en kopi af MTA-STS-politikken for gmail.com osv. For et lille firma eller en privatperson med eget domæne yder MTA-STS ikke den store sikkerhed udover ved modtagelse af mail fra mailservere, man jævnligt er i kontakt med.

MTA-STS er en erstatning for DANE for folk, der ønsker mailsikkerhed men ikke kan/vil bruge DNSSEC. Hvorfor er det lige, at folk ikke ønsker at implementere DNSSEC? De fleste DNS-hosts understøtter det efterhånden (med Amazon Route 53 som en prominent undtagelse). En stor spiller som Google ville nemt kunne aktivere DNSSEC for gmail.com, hvis de ønskede, men det har de ikke gjort. De har sikkert gode grunde til at lade være (sikkert et forsigtighedsprincip), men jeg ved ikke, hvad de er.

Log ind eller Opret konto for at kommentere