Kort sagt er MTA-STS en måde at beskytte e-mails yderligere mod aflytning (dvs. man-in-the-middle-angreb aka MitM), når de transmitteres mellem mailservere. Det løser delvist de gamle arkitektoniske problemer med e-mail-protokoller og er beskrevet i den relativt nye standard RFC 8461. Mail.ru er den første store mailtjeneste på RuNet, der implementerer denne standard. Og det er beskrevet nærmere under snittet.

Hvilket problem løser MTA-STS?

Historisk set har e-mail-protokoller (SMTP, POP3, IMAP) transmitteret information i klartekst, hvilket gjorde det muligt at opsnappe det, for eksempel ved adgang til en kommunikationskanal.

Hvordan ser mekanismen til at levere et brev fra én bruger til en anden ud:

Historisk set var et MitM-angreb muligt alle steder, hvor post cirkulerer.

RFC 8314 kræver brug af TLS mellem mailbrugerapplikationen (MUA) og mailserveren. Hvis din server og de mailapplikationer du bruger er kompatible med RFC 8314, så har du (stort set) elimineret muligheden for Man-in-the-Middle-angreb mellem brugeren og mailserverne.

At følge almindeligt accepteret praksis (standardiseret af RFC 8314) eliminerer angrebet i nærheden af brugeren:

Mail.ru-mailservere overholdt RFC 8314, selv før standarden blev vedtaget; faktisk fanger den simpelthen allerede accepteret praksis, og vi behøvede ikke at konfigurere noget yderligere. Men hvis din mailserver stadig tillader brugere at bruge usikre protokoller, skal du sørge for at implementere anbefalingerne fra denne standard, fordi Mest sandsynligt arbejder i det mindste nogle af dine brugere med mail uden kryptering, selvom du understøtter det.

Mailklienten arbejder altid med den samme mailserver i den samme organisation. Og du kan tvinge alle brugere til at oprette forbindelse på en sikker måde, og så gøre det teknisk umuligt for ikke-sikre brugere at oprette forbindelse (det er præcis, hvad RFC 8314 kræver). Dette er nogle gange svært, men det kan lade sig gøre. Trafik mellem mailservere er stadig mere kompliceret. Servere tilhører forskellige organisationer og bruges ofte i en "indstil og glem"-tilstand, hvilket gør det umuligt at skifte til en sikker protokol på én gang uden at afbryde forbindelsen. SMTP har længe leveret STARTTLS-udvidelsen, som gør det muligt for servere, der understøtter kryptering, at skifte til TLS. Men en angriber, der har evnen til at påvirke trafikken, kan "klippe ud" information om understøttelse af denne kommando og tvinge serverne til at kommunikere ved hjælp af en almindelig tekstprotokol (det såkaldte nedgraderingsangreb). Af samme grund kontrollerer STARTTLS normalt ikke certifikatets gyldighed (et certifikat, der ikke er tillid til, kan beskytte mod passive angreb, og det er ikke værre end at sende en besked i klartekst). Derfor beskytter STARTTLS kun mod passiv aflytning.

MTA-STS eliminerer delvist problemet med at opsnappe breve mellem mailservere, når angriberen har mulighed for aktivt at påvirke trafikken. Hvis modtagerens domæne udgiver en MTA-STS-politik, og afsenderens server understøtter MTA-STS, vil den kun sende e-mailen over en TLS-forbindelse, kun til servere defineret af politikken, og kun med verifikation af serverens certifikat.

Hvorfor delvist? MTA-STS virker kun, hvis begge parter har sørget for at implementere denne standard, og MTA-STS beskytter ikke mod scenarier, hvor en angriber er i stand til at få et gyldigt domænecertifikat fra en af de offentlige CA'er.

Hvordan MTA-STS virker

Modtager

Konfigurerer STARTTLS-understøttelse med et gyldigt certifikat på mailserveren.
Udgiver MTA-STS-politikken via HTTPS; et særligt mta-sts-domæne og en særlig velkendt sti bruges til udgivelse, f.eks. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politikken indeholder en liste over mailservere (mx), der har ret til at modtage mail for dette domæne.
Udgiver en speciel TXT-post _mta-sts i DNS med politikversionen. Når politikken ændres, skal denne post opdateres (dette signalerer, at afsenderen skal forespørge politikken igen). For eksempel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

afsender

Afsenderen anmoder om _mta-sts DNS-posten, og hvis den er tilgængelig, laver en politikanmodning via HTTPS (kontrollerer certifikatet). Den resulterende politik cachelagres (i tilfælde af at en hacker blokerer adgang til den eller forfalsker DNS-posten).

Ved afsendelse af mail kontrolleres det, at:

serveren, hvortil posten leveres, er i politikken;
serveren accepterer mail ved hjælp af TLS (STARTTLS) og har et gyldigt certifikat.

Fordele ved MTA-STS

MTA-STS bruger teknologier, der allerede er implementeret i de fleste organisationer (SMTP+STARTTLS, HTTPS, DNS). For implementering på modtagersiden kræves ingen speciel softwaresupport til standarden.

Ulemper ved MTA-STS

Det er nødvendigt at overvåge gyldigheden af web- og mailservercertifikatet, korrespondancen af navne og rettidig fornyelse. Problemer med certifikatet vil resultere i, at post ikke kan leveres.

På afsendersiden kræves en MTA med understøttelse af MTA-STS-politikker; i øjeblikket understøttes MTA-STS ikke direkte i MTA'en.

MTA-STS bruger en liste over betroede rod-CA'er.

MTA-STS beskytter ikke mod angreb, hvor angriberen bruger et gyldigt certifikat. I de fleste tilfælde indebærer MitM i nærheden af serveren muligheden for at udstede et certifikat. Et sådant angreb kan detekteres ved hjælp af Certificate Transparency. Derfor mindsker MTA-STS generelt, men eliminerer ikke fuldstændigt, muligheden for trafikaflytning.

De sidste to punkter gør MTA-STS mindre sikker end den konkurrerende DANE-standard for SMTP (RFC 7672), men mere teknisk pålidelig, dvs. for MTA-STS er der en lav sandsynlighed for, at brevet ikke bliver leveret på grund af tekniske problemer forårsaget af implementeringen af standarden.

Konkurrerende standard - DANSK

DANE bruger DNSSEC til at offentliggøre certifikatoplysninger og kræver ikke tillid til eksterne certifikatmyndigheder, hvilket er meget mere sikkert. Men brugen af DNSSEC fører væsentligt oftere til tekniske fejl, baseret på statistik over flere års brug (selvom der generelt er en positiv tendens i pålideligheden af DNSSEC og dets tekniske support). For at implementere DANE i SMTP på modtagersiden er tilstedeværelsen af DNSSEC for DNS-zonen obligatorisk, og korrekt understøttelse af NSEC/NSEC3 er afgørende for DANE, som der er systemiske problemer med i DNSSEC.

Hvis DNSSEC ikke er konfigureret korrekt, kan det resultere i postleveringsfejl, hvis afsendersiden understøtter DANE, selvom den modtagende side ikke ved noget om det. Derfor, på trods af at DANE er en ældre og mere sikker standard og allerede understøttes i noget serversoftware på afsendersiden, er dens indtrængen faktisk stadig ubetydelig, mange organisationer er ikke klar til at implementere den på grund af behovet for at implementere DNSSEC, det har bremset implementeringen af DANE markant i alle de år, standarden har eksisteret.

DANE og MTA-STS er ikke i konflikt med hinanden og kan bruges sammen.

Hvad er der med MTA-STS-understøttelse i Mail.ru Mail?

Mail.ru har udgivet en MTA-STS-politik for alle større domæner i et stykke tid. Vi er i øjeblikket ved at implementere klientdelen af standarden. I skrivende stund anvendes politikker i en ikke-blokerende tilstand (hvis levering er blokeret af en politik, vil brevet blive leveret gennem en "reserve"-server uden at anvende politikker), så vil blokeringstilstand være tvunget til en lille del af udgående SMTP-trafik, vil det gradvist for 100 % af trafikken være Håndhævelse af politikker understøttes.

Hvem støtter ellers standarden?

Indtil videre har MTA-STS-politikker offentliggjort cirka 0.05 % af de aktive domæner, men ikke desto mindre beskytter de allerede en stor mængde mailtrafik, fordi Standarden understøttes af store aktører – Google, Comcast og til dels Verizon (AOL, Yahoo). Mange andre posttjenester har meddelt, at understøttelse af standarden vil blive implementeret i den nærmeste fremtid.

Hvordan vil dette påvirke mig?

Ikke medmindre dit domæne udgiver en MTA-STS-politik. Hvis du udgiver politikken, vil e-mails til brugere af din mailserver være bedre beskyttet mod aflytning.

Hvordan implementerer jeg MTA-STS?

MTA-STS support på modtagersiden

Det er nok at offentliggøre politikken via HTTPS og poster i DNS, konfigurere et gyldigt certifikat fra en af de betroede CA'er (Lad os kryptere er muligt) for STARTTLS i MTA'en (STARTTLS understøttes i alle moderne MTA'er), ingen særlig support fra MTA er påkrævet.

Trin for trin ser det sådan ud:

Konfigurer STARTTLS i den MTA du bruger (postfix, exim, sendmail, Microsoft Exchange osv.).
Sørg for, at du bruger et gyldigt certifikat (udstedt af en betroet CA, ikke udløbet, emnet for certifikatet matcher MX-posten, der leverer mail til dit domæne).
Konfigurer en TLS-RPT-post, gennem hvilken politikapplikationsrapporter vil blive leveret (af tjenester, der understøtter afsendelse af TLS-rapporter). Eksempel på post (for domænet example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Denne post instruerer postafsendere til at sende statistiske rapporter om TLS-brug i SMTP til [email protected].

Overvåg rapporterne i flere dage for at sikre, at der ikke er fejl.
Udgiv MTA-STS-politikken over HTTPS. Politikken udgives som en tekstfil med CRLF-linjeterminatorer efter lokation.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Eksempel på politik:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Versionsfeltet indeholder versionen af politikken (i øjeblikket STSv1), Tilstand indstiller politikapplikationstilstanden, test - testtilstand (politikken anvendes ikke), håndhæv - "kamp"-tilstand. Udgiv først politikken med tilstand: test, hvis der ikke er problemer med politikken i testtilstand, kan du efter et stykke tid skifte til tilstand: håndhæv.

I mx er der angivet en liste over alle mailservere, der kan acceptere mail for dit domæne (hver server skal have et certifikat konfigureret, der matcher navnet angivet i mx). Max_age angiver cachetiden for politikken (når den huskede politik vil blive anvendt, selvom angriberen blokerer dens levering eller korrumperer DNS-posterne i cachetiden, kan du signalere behovet for at anmode om politikken igen ved at ændre mta-sts DNS optage).
Udgiv en TXT-post i DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
En vilkårlig identifikator (f.eks. et tidsstempel) kan bruges i id-feltet; når politikken ændres, bør den ændres, hvilket gør det muligt for afsendere at forstå, at de skal genanmode om den cachelagrede politik (hvis identifikatoren er forskellig fra en cache).

MTA-STS støtte på afsendersiden

Indtil videre er det dårligt med hende, fordi... frisk standard.

Exim - ingen indbygget support, der er et tredjepartsscript https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - der er ingen indbygget support, der er et tredjeparts script som er beskrevet detaljeret på Habré https://habr.com/en/post/424961/

Som et efterord om "obligatorisk TLS"

På det seneste har regulatorer været opmærksomme på e-mail-sikkerhed (og det er en god ting). For eksempel er DMARC obligatorisk for alle offentlige myndigheder i USA og er i stigende grad påkrævet i den finansielle sektor, med indtrængning af standarden på 90 % i regulerede områder. Nu kræver nogle regulatorer implementering af "obligatorisk TLS" med individuelle domæner, men mekanismen til at sikre "obligatorisk TLS" er ikke defineret, og i praksis implementeres denne indstilling ofte på en måde, der ikke engang minimalt beskytter mod reelle angreb, der allerede er forudsat i mekanismer som DANE eller MTA-STS.

Hvis regulatoren kræver implementering af "obligatorisk TLS" med separate domæner, anbefaler vi at overveje MTA-STS eller dens delvise analoge som den bedst egnede mekanisme, det eliminerer behovet for at lave sikre indstillinger for hvert domæne separat. Hvis du har problemer med at implementere klientdelen af MTA-STS (indtil protokollen har modtaget bred støtte, vil de højst sandsynligt gøre det), kan vi anbefale denne tilgang:

Udgiv en MTA-STS-politik og/eller DANE-registreringer (DANE giver kun mening, hvis DNSSEC allerede er aktiveret for dit domæne, og MTA-STS under alle omstændigheder), dette vil beskytte trafikken i din retning og eliminere behovet for at spørge andre e-mail-tjenester at konfigurere obligatorisk TLS for dit domæne, hvis mailtjenesten allerede understøtter MTA-STS og/eller DANE.
For store e-mail-tjenester skal du implementere en "analog" af MTA-STS gennem separate transportindstillinger for hvert domæne, som vil rette den MX, der bruges til mail-relay, og vil kræve obligatorisk verifikation af et TLS-certifikat for det. Hvis domænerne allerede udgiver en MTA-STS-politik, kan dette sandsynligvis gøres smertefrit. Aktivering af obligatorisk TLS for et domæne uden at rette relæet og bekræfte certifikatet for det er i sig selv ineffektivt ud fra et sikkerhedssynspunkt og tilføjer ikke noget til de eksisterende STARTTLS-mekanismer.

Kilde: www.habr.com

Mail.ru-mail begynder at anvende MTA-STS-politikker i testtilstand