Kort sagt er MTA-STS en metode til at beskytte emails mod interception (dvs. mand-i-midt angreb aka MitM) under transmission mellem mailservere. Det adresserer delvist eksisterende arkitektoniske problemer i emailprotokoller og er beskrevet i den relativt nye standard RFC 8461. Mail.ru er den første store mailtjeneste i Rusland, der implementerer denne standard. Der gives en mere detaljeret forklaring længere nede.

Hvad problem løser MTA-STS?

Historisk set har emailprotokoller (SMTP, POP3, IMAP) sendt informationer i klar tekst, hvilket gør det muligt at opfange dem, for eksempel ved adgang til kommunikationskanalen.

Hvordan ser mekanismen for levering af en email fra en bruger til en anden ud:

Historisk set har MitM angreb været mulige alle steder, hvor post passerer.

RFC 8314 standarden kræver obligatorisk brug af TLS mellem brugerens mailprogram (MUA) og mailserveren. Hvis din server og de anvendte mailapplikationer overholder RFC 8314, så har du (i høj grad) elimineret muligheden for Man-in-the-Middle angreb mellem brugeren og mailserverne.

Overholdelse af anerkendte praksisser (standardiserede RFC 8314) eliminerer angreb tæt på brugeren:

Mail.ru's mailservere overholdt RFC 8314 allerede før standardens vedtagelse; faktisk bekræftede den blot allerede vedtagne praksisser, og vi behøvede ikke at foretage yderligere indstillinger. Men hvis din mailserver stadig tillader brugere at kommunikere via usikre protokoller, bør du helt sikkert implementere anbefalingerne fra denne standard, da det sandsynligvis betyder, at mindst en del af dine brugere benytter email uden kryptering, selvom du understøtter det.

Mailklienten arbejder altid med den samme mailserver fra den samme organisation. Det er muligt at tvinge alle brugere til at oprette forbindelse på en sikker måde, hvorefter det teknisk bliver umuligt at etablere usikre forbindelser (som krævet af RFC 8314). Dette kan være komplekst, men det er muligt. Med trafik mellem mailserverne er det endnu mere kompliceret. Serverne tilhører forskellige organisationer og bruges ofte i en 'sæt og glem'-tilstand, hvilket gør øjeblikkelig overgang til en sikker protokol umulig uden at bryde forbindelsen. I SMTP har der længe været en udvidelse kaldet STARTTLS, der gør det muligt for servere, der understøtter kryptering, at skifte til TLS. Men en angriber, der er i stand til at påvirke trafikken, kan 'fjerne' information om understøttelsen af denne kommando og tvinge serverne til at kommunikere via den almindelige tekstprotokol (såkaldt downgrade attack). Af samme grund tjekkes der normalt ikke certifikatoverensstemmelse for STARTTLS (et ikke-betroet certifikat kan beskytte mod passive angreb, og det er ikke værre end at sende en e-mail i klartekst). Derfor beskytter STARTTLS kun mod passiv aflytning.

MTA-STS delvist løser problemet med aflytning af e-mails mellem mailserverne, når en angriber har mulighed for aktivt at påvirke trafikken. Hvis modtagerdommens publikerer en MTA-STS-politik, og afsenderserveren understøtter MTA-STS, vil den sende e-mailen kun via en TLS-forbindelse, kun til servere specificeret i politikken, og kun med validering af servercertifikatet.

Hvorfor kun delvist? MTA-STS fungerer kun hvis begge parter har taget sig af at implementere denne standard, og MTA-STS beskytter ikke mod scenarier, hvor en angriber har mulighed for at få et gyldigt domænecertifikat fra en af de offentlige CA'er.

Hvordan fungerer MTA-STS

Modtageren

Konfigurerer understøttelse af STARTTLS med et gyldigt certifikat på mailserveren.
Offentliggør MTA-STS-politikken via HTTPS; der anvendes et specielt domæne mta-sts og en speciel well-known sti, for eksempel 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.
Publicerer en speciel TXT-post _mta-sts i DNS med politikversion. Når politikken ændres, skal denne post opdateres (det signalerer til afsenderen, at den skal anmode om politikken igen). For eksempel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Afsender

Afsenderen anmoder om DNS-posten _mta-sts, og hvis den findes, laver den en politikforespørgsel via HTTPS (med kontrol af certifikatet). Den modtagne politik caches (i tilfælde af, at en angriber blokerer adgangen til den eller ændrer DNS-posten).

Ved afsendelse af e-mails kontrolleres det, at:

serveren, som e-mailen leveres til, er i politikken;
serveren modtager e-mail med brug 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). Der kræves ikke særlig softwareunderstøttelse af standarden på modtagerens side.

Ulemper ved MTA-STS

Det er nødvendigt at holde øje med gyldigheden af certifikaterne for web- og mailservere, overensstemmelse af navne, samt rettidig opdatering. Problemer med certifikatet vil føre til, at e-mailen ikke kan leveres.

På afsenderens side kræves en MTA, der understøtter MTA-STS-politikker; i øjeblikket understøttes MTA-STS ikke 'out of the box' i MTA.

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

MTA-STS beskytter ikke mod angreb, hvor en angriber bruger et gyldigt certifikat. I de fleste tilfælde involverer MitM tæt på serveren muligheden for at udstede et certifikat. Sådan et angreb kan opdages takket være Certificate Transparency. Så i det hele taget mitigere MTA-STS, men fjerner ikke helt muligheden for at intercept trafik.

De to sidste punkter gør MTA-STS mindre sikker end den konkurrerende standard DANE for SMTP (RFC 7672), men mere teknisk pålidelig, dvs. for MTA-STS er sandsynligheden for, at en e-mail ikke leveres på grund af tekniske problemer forårsaget af standardens implementering lav.

Den konkurrerende standard er DANE

DANE bruger DNSSEC til at offentliggøre oplysninger om certifikater og kræver ikke tillid til eksterne certifikatmyndigheder, hvilket er langt sikrere. Men brugen af DNSSEC fører markant oftere til tekniske fejl, hvis man ser på statistikker fra flere års anvendelse (selv om der generelt er positive tendenser i pålideligheden af DNSSEC og dens tekniske support). For at implementere DANE i SMTP på modtagerens side er det nødvendigt, at DNSSEC er aktiveret for DNS-zonen, og korrekt understøttelse af NSEC/NSEC3 er væsentlig, da der er systematiske problemer med dette i DNSSEC.

Hvis DNSSEC er konfigureret forkert, kan det føre til problemer med maillevering, hvis afsenderen understøtter DANE, selvom modtageren ikke ved noget om det. Derfor, selvom DANE er en ældre og mere sikker standard og allerede er understøttet i visse serverprogrammer på afsenderens side, er det faktiske udbredelse stadig meget begrænset. Mange organisationer er ikke parate til at implementere det på grund af behovet for at realisere DNSSEC, hvilket har bremset implementeringen af DANE gennem de år, standarden har eksisteret.

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

Hvordan er understøttelsen af MTA-STS i Mail.ru?

Mail.ru har længe offentliggjort MTA-STS-politik for alle større domæner. Vi arbejder nu på at implementere klientdelen af standarden. På tidspunktet for denne artikels skrivning anvendes politikker i en ikke-blokerende tilstand (hvis leveringen blokeres af politikken, vil mailen blive leveret via en 'backup'-server uden anvendelse af politikker), og derefter vil den blokerende tilstand blive påtvunget for en lille del af den udsendte SMTP-trafik, og gradvist vil 100% af trafikken støtte anvendelsen af politikker.

Hvem andre understøtter standarden?

I øjeblikket offentliggør cirka 0,05% af aktive domæner MTA-STS-politikker, men de beskytter allerede et stort volumen af mailtrafik, da store aktører som Google, Comcast og delvist Verizon (AOL, Yahoo) understøtter standarden. Mange andre mailtjenester har erklæret, at understøttelsen af standarden vil blive implementeret i den nærmeste fremtid.

Hvordan vil dette påvirke mig?

Ikke, hvis dit domæne ikke offentliggør en MTA-STS-politik. Hvis du offentliggør en politik, vil e-mails til brugere af din mailserver være bedre beskyttet mod aflytning.

Hvordan implementerer jeg MTA-STS?

Understøttelse af MTA-STS på modtagerens side

Det er tilstrækkeligt at offentliggøre en politik via HTTPS og DNS-poster, konfigurere et gyldigt certifikat fra en af de betroede CA'er (for eksempel Let's Encrypt) til STARTTLS i MTA (STARTTLS understøttes i alle moderne MTA'er), speciel support fra MTA er ikke nødvendig.

I trin ser det således ud:

Konfigurer STARTTLS i den MTA, du bruger (postfix, exim, sendmail, Microsoft Exchange osv.).
Sørg for, at et gyldigt certifikat anvendes (udstedt af en betroet CA, ikke udløbet, certifikatets emne svarer til MX-posten, hvor mailen til dit domæne leveres).
Konfigurer TLS-RPT-posten, hvor rapporter om politikløsning vil blive sendt (af tjenester, der understøtter afsendelse af TLS-rapporter). Eksempel på optegnelse (for domænet example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Denne post instruerer mailafsendere til at sende statistiske rapporter om brugen af TLS i SMTP til adressen tlsrpt@exmple.com.
Hold øje med rapporterne i et par dage, og sørg for, at der ikke er fejl.
Offentliggør MTA-STS-politikken via HTTPS. Politikken offentliggøres som en tekstfil med CRLF linjeskift.
```
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
```
Feltet version indeholder den version af politikken (nu er det STSv1), mode angiver politikforløbsmodus, testing - testmodus (politikken anvendes ikke), enforce - 'produktions' modus. Offentliggør først politikken med mode: testing, hvis der ikke opstår problemer med politikken i testmodus, kan du efter et stykke tid skifte til mode: enforce.
I mx angives en liste over alle mailservere, der kan modtage mails til dit domæne (hver server skal have et certifikat konfigureret, der svarer til navnet angivet i mx). Max_age angiver cachetiden for politikken (en gang gemt, vil politikken anvendes, selvom en angriber blokerer dens levering eller ødelægger DNS-poster i cachetiden, signaleres behovet for at anmode om politikken igen ved at ændre mta-sts DNS-posten).
Offentliggør en DNS TXT-post:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
I felt id kan bruges en vilkårlig identifikator (f.eks. et tidsstempel), når politikken ændres, skal den ændres, så afsenderne kan forstå, at de skal anmode om at genindlæse den cachede politik (hvis identifikatoren er forskellig fra den cachede).

Understøttelse af MTA-STS på afsenderens side

Det står ikke så godt til endnu, da standarden er ny.

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

Som en efterord om 'mandatory TLS'

For nylig har regulativerne begyndt at fokusere på sikkerheden af e-mails (og det er godt). For eksempel er DMARC obligatorisk for alle statslige institutioner i USA og bliver oftere krævet i finanssektoren, i regulerede områder når standarden næsten 90%. I øjeblikket kræver nogle regulativer implementering af 'mandatory TLS' med specifikke domæner, men mekanismen til at sikre 'mandatory TLS' er ikke defineret, og i praksis bliver denne indstilling ofte implementeret på en måde, der ikke engang mindsker risikoen mod reelle angreb, som allerede er forudset i sådanne mekanismer som DANE eller MTA-STS.

Hvis regulatøren kræver implementering af 'mandatory TLS' med specifikke domæner, anbefaler vi at overveje MTA-STS eller dens delvise analog som den mest passende mekanisme, det fjerner behovet for at lave sikre indstillinger for hvert enkelt domæne. Hvis du har vanskeligheder med implementeringen af klientdelen af MTA-STS (indtil protokol ikke får bred støtte, vil de sandsynligvis eksistere), kan denne tilgang anbefales:

Publicer MTA-STS politikken og/eller DANE poster (DANE giver mening at tilføje kun hvis DNSSEC allerede er aktiveret for dit domæne, og MTA-STS i hvert fald), det vil beskytte trafikken mod din side og fritage dig for at skulle bede andre e-mail tjenester om at indstille mandatory TLS for dit domæne, hvis e-mail tjenesten allerede understøtter MTA-STS og/eller DANE.
For large email services, implement an "equivalent" of MTA-STS through separate transport settings for each domain, which will record the MX used for mail relaying and require mandatory TLS certificate verification. If the domains already publish an MTA-STS policy, this can likely be done without pain. Enabling mandatory TLS for a domain without fixing the relay and verifying the certificate is ineffective from a security standpoint and adds nothing to the existing STARTTLS mechanisms.

Kilde: habr.com