Kort sagt er MTA-STS en måte å i tillegg beskytte e-poster mot avlytting (dvs. man-in-the-middle-angrep, også kjent som MitM) ved overføring mellom e-postservere. Det løser delvis de eldre arkitekturproblemene til e-postprotokoller og er beskrevet i den relativt nye RFC 8461-standarden. Mail.ru er den første store e-posttjenesten i RuNet som implementerer denne standarden. Flere detaljer finner du nedenfor.

Hvilket problem løser MTA-STS?

Historisk sett overførte e-postprotokoller (SMTP, POP3, IMAP) informasjon i klartekst, noe som gjorde det mulig å fange den opp, for eksempel når man fikk tilgang til en kommunikasjonskanal.

Hvordan ser mekanismen for å levere et brev fra én bruker til en annen ut:

Historisk sett har et MitM-angrep vært mulig på alle steder der post reiser.

RFC 8314 krever obligatorisk bruk av TLS mellom brukerens e-postprogram (MUA) og e-postserveren. Hvis serveren din og e-postprogrammene du bruker overholder RFC 8314, har du (i stor grad) eliminert muligheten for Man-in-the-Middle-angrep mellom brukeren og e-postserverne.

Å følge vanlige fremgangsmåter (standardisert av RFC 8314) eliminerer angrepet nær brukeren:

Mail.ru-e-postservere overholdt RFC 8314 allerede før standarden ble tatt i bruk. Faktisk registrerer den bare allerede aksepterte fremgangsmåter, og vi trengte ikke å konfigurere noe i tillegg. Men hvis e-postserveren din fortsatt lar brukere gå gjennom usikre protokoller, må du sørge for å implementere anbefalingene i denne standarden, siden det mest sannsynlig er at i det minste noen av brukerne dine jobber med e-post uten kryptering, selv om du støtter det.

En e-postklient jobber alltid med den samme e-postserveren til samme organisasjon. Og det er mulig å tvinge alle brukere til å koble seg sikkert til, og deretter gjøre det teknisk umulig å koble seg til usikkert (dette er hva RFC 8314 krever). Dette er noen ganger vanskelig, men gjennomførbart. Med trafikk mellom e-postservere er det enda mer komplisert. Servere tilhører forskjellige organisasjoner og brukes ofte i "sett og glem"-modus, noe som gjør det umulig å samtidig bytte til en sikker protokoll uten å bryte tilkoblingen. SMTP har lenge hatt en STARTTLS-utvidelse, som lar servere som støtter kryptering bytte til TLS. Men en angriper som har muligheten til å påvirke trafikken kan "kutte ut" informasjon om støtte for denne kommandoen og tvinge servere til å kommunisere ved hjelp av en vanlig tekstprotokoll (det såkalte nedgraderingsangrepet). Av samme grunn sjekker STARTTLS vanligvis ikke sertifikatsamsvaret (et upålitelig sertifikat kan beskytte mot passive angrep, og dette er ikke verre enn å sende et brev i ren tekst). Derfor beskytter STARTTLS bare mot passiv avlytting.

MTA-STS eliminerer delvis problemet med avlytting av brev mellom e-postservere, når angriperen har muligheten til å aktivt påvirke trafikken. Hvis mottakerens domene publiserer en MTA-STS-policy, og avsenderens server støtter MTA-STS, vil den bare sende brevet gjennom en TLS-tilkobling, bare til servere definert av policyen, og bare med verifisering av serversertifikatet.

Hvorfor delvis? MTA-STS fungerer bare hvis begge parter har sørget for å implementere denne standarden, og MTA-STS beskytter ikke mot scenarier der en angriper har muligheten til å skaffe et gyldig domenesertifikat fra en av de offentlige CA-ene.

Hvordan MTA-STS fungerer

mottakeren

Konfigurerer STARTTLS-støtte med et gyldig sertifikat på e-postserveren.
Publiserer MTA-STS-policy via HTTPS, ved bruk av et spesielt mta-sts-domene og en spesiell kjent publiseringssti, for eksempel https://mta-sts.mail.ru/.well-known/mta-sts.txtPolicyen inneholder en liste over e-postservere (mx) som er autorisert til å motta e-post for dette domenet.
Publiserer en spesiell _mta-sts TXT-post i DNS med policyversjonen. Når policyen endres, bør denne posten oppdateres (dette signaliserer til avsenderen at den skal spørre policyen på nytt). For eksempel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Avsender

Avsenderen ber om DNS-posten _mta-sts, og hvis den finnes, sender en policyforespørsel via HTTPS (ved å sjekke sertifikatet). Den mottatte policyen blir mellomlagret (i tilfelle angriperen blokkerer tilgang til den eller erstatter DNS-posten).

Når du sender e-post, kontrolleres det at:

serveren som e-post leveres til er angitt i policyen;
Serveren godtar e-post ved hjelp av TLS (STARTTLS) og har et gyldig sertifikat.

Fordeler med MTA-STS

MTA-STS bruker teknologier som allerede er implementert i de fleste organisasjoner (SMTP+STARTTLS, HTTPS, DNS). Ingen spesiell programvarestøtte for standarden er nødvendig for implementering på mottakersiden.

Ulemper med MTA-STS

Det er nødvendig å overvåke gyldigheten av web- og e-postserversertifikatet, navnesamsvar og rettidig fornyelse. Problemer med sertifikatet vil føre til at det ikke er mulig å levere post.

På avsendersiden kreves en MTA med støtte for MTA-STS-policyer. For øyeblikket støttes ikke MTA-STS direkte i MTA.

MTA-STS bruker en liste over klarerte rot-CA-er.

MTA-STS beskytter ikke mot angrep der angriperen bruker et gyldig sertifikat. I de fleste tilfeller innebærer MitM nær serveren muligheten for å utstede et sertifikat. Et slikt angrep kan oppdages ved hjelp av sertifikattransparens. Derfor reduserer MTA-STS generelt muligheten for trafikkavlytting, men eliminerer ikke fullstendig.

De to siste punktene gjør MTA-STS mindre sikker enn den konkurrerende DANE-standarden for SMTP (RFC 7672), men mer teknisk pålitelig, dvs. for MTA-STS er det lav sannsynlighet for at et brev ikke blir levert på grunn av tekniske problemer forårsaket av implementeringen av standarden.

Konkurrerende standard - DANE

DANE bruker DNSSEC til å publisere sertifikatinformasjon og krever ikke tillit til eksterne sertifiseringsinstanser, noe som er mye sikrere. Men bruken av DNSSEC fører betydelig oftere til tekniske feil, hvis vi stoler på statistikk over flere års bruk (selv om påliteligheten til DNSSEC og den tekniske støtten generelt er positiv). For å implementere DANE i SMTP på mottakersiden er tilstedeværelsen av DNSSEC for DNS-sonen obligatorisk, og for DANE er korrekt støtte for NSEC/NSEC3 avgjørende, noe DNSSEC har systemiske problemer med.

Hvis DNSSEC er feil konfigurert, kan det føre til feil i e-postleveringen hvis avsendersiden støtter DANE, selv om mottakersiden ikke vet om det. Så til tross for at DANE er en eldre og sikrere standard og allerede støttes i noe serverprogramvare på avsendersiden, er dens gjennomtrengning fortsatt ubetydelig. Mange organisasjoner er ikke klare til å implementere den på grunn av behovet for å implementere DNSSEC. Dette har bremset implementeringen av DANE betydelig i alle årene standarden har eksistert.

DANE og MTA-STS er ikke i konflikt med hverandre og kan brukes sammen.

Hva med MTA-STS-støtte i Mail.ru Mail

Mail.ru har publisert MTA-STS-policyen for alle større domener i en god stund nå. Vi implementerer for tiden klientdelen av standarden. I skrivende stund brukes policyene i ikke-blokkerende modus (hvis levering blokkeres av policyen, vil brevet bli levert via "backup"-serveren uten å bruke policyer), deretter vil blokkeringsmodusen bli tvunget for en liten del av utgående SMTP-trafikk, og gradvis vil bruk av policyer støttes for 100 % av trafikken.

Hvem andre støtter standarden?

Selv om MTA-STS-policyer for øyeblikket publiseres av omtrent 0.05 % av aktive domener, beskytter de allerede et stort volum av e-posttrafikk, ettersom standarden støttes av store aktører – Google, Comcast og delvis Verizon (AOL, Yahoo). Mange andre e-posttjenester har annonsert at støtte for standarden vil bli implementert i nær fremtid.

Hvordan vil dette påvirke meg?

Ikke i det hele tatt, med mindre domenet ditt publiserer MTA-STS-policyen. Hvis du publiserer policyen, vil e-poster for brukere av e-postserveren din være bedre beskyttet mot avlytting.

Hvordan implementerer jeg MTA-STS?

MTA-STS-støtte på mottakersiden

Det er nok å publisere policyen via HTTPS og DNS-oppføringer, konfigurere et gyldig sertifikat fra en av de pålitelige CA-ene (Let's encrypt er mulig) for STARTTLS i MTA (STARTTLS støttes i alle moderne MTA-er), ingen spesiell støtte fra MTA er nødvendig.

Steg for steg ser det slik ut:

Konfigurer STARTTLS i MTA-en du bruker (postfix, exim, sendmail, Microsoft Exchange osv.).
Sørg for at du bruker et gyldig sertifikat (utstedt av en klarert CA, ikke utløpt, og at sertifikatets emne samsvarer med MX-posten som leverer e-post for domenet ditt).
Konfigurer en TLS-RPT-post for å levere rapporter om håndheving av retningslinjer (av tjenester som støtter sending av TLS-rapporter). Eksempelpost (for domenet example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»
```
Denne oppføringen instruerer e-postavsendere til å sende statistiske rapporter om TLS-bruk i SMTP til adressen tlsrpt@exmple.com.
Overvåk rapportene i noen dager for å sikre at det ikke er noen feil.
Publiser MTA-STS-policyen over HTTPS. Policyen publiseres som en tekstfil med CRLF-linjeavslutninger etter plassering.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Eksempel på policy:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Versjonsfeltet inneholder policyversjonen (for øyeblikket er den STSv1), Modus angir modusen for policyapplikasjon, testing er testmodusen (policyen brukes ikke), enforce er "kamp"-modusen. Publiser først policyen med modus: testing. Hvis det ikke er noen problemer med policyen i testmodus, kan du etter en stund bytte til modus: enforce.
mx angir en liste over alle e-postservere som kan godta e-post for domenet ditt (hver server må ha et konfigurert sertifikat som samsvarer med navnet angitt i mx). Max_age angir mellomlagringstiden for policyen (når policyen er husket, vil den bli brukt selv om angriperen blokkerer returen eller ødelegger DNS-poster i løpet av mellomlagringstiden. Du kan signalisere behovet for å spørre policyen på nytt ved å endre DNS-posten mta-sts).
Publiser en TXT-oppføring i DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
ID-feltet kan være en vilkårlig identifikator (f.eks. et tidsstempel), og den bør endres når policyen endres. Dette gjør at avsendere forstår at de må be om den hurtigbufrede policyen på nytt (hvis identifikatoren er forskjellig fra den hurtigbufrede).

MTA-STS-støtte på avsendersiden

Det går dårlig med henne foreløpig, fordi standarden er ny.

Exim - ingen innebygd støtte, tredjepartsskript tilgjengelig https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — ingen innebygd støtte, det finnes et tredjepartsskript som er beskrevet i detalj på Habr https://habr.com/en/post/424961/

Som et etterord om «obligatorisk TLS»

Regulatorer har i det siste vært oppmerksomme på e-postsikkerhet (og det er bra). For eksempel er DMARC obligatorisk for alle offentlige etater i USA og i økende grad påkrevd i finanssektoren, med penetrasjonsrater som når 90 % i regulerte områder. Noen regulatorer krever nå implementering av «obligatorisk TLS» med individuelle domener, men mekanismen for å sikre «obligatorisk TLS» er ikke definert, og i praksis implementeres denne innstillingen ofte på en måte som ikke engang minimalt beskytter mot reelle angrep som allerede er gitt i mekanismer som DANE eller MTA-STS.

Hvis regulatoren krever implementering av "obligatorisk TLS" med individuelle domener, anbefaler vi å vurdere MTA-STS eller dens delvise analog som den mest passende mekanismen, da det eliminerer behovet for å gjøre sikkerhetsinnstillinger for hvert domene separat. Hvis du har problemer med implementeringen av klientdelen av MTA-STS (inntil protokollen har fått bred støtte, vil de mest sannsynlig få det), kan vi anbefale følgende tilnærming:

Publiser MTA-STS-policy og/eller DANE-oppføringer (DANE gir bare mening hvis DNSSEC allerede er aktivert for domenet ditt, og MTA-STS i alle fall). Dette vil beskytte trafikken til deg og eliminere behovet for å be andre e-posttjenester om å konfigurere obligatorisk TLS for domenet ditt hvis e-posttjenesten allerede støtter MTA-STS og/eller DANE.
For store e-posttjenester, implementer en "analog" av MTA-STS gjennom separate transportinnstillinger for hvert domene, noe som vil fikse MX-en som brukes til videresending av e-post og kreve obligatorisk TLS-sertifikatverifisering for det. Hvis domenene allerede publiserer MTA-STS-policy, kan dette mest sannsynlig gjøres smertefritt. Å aktivere obligatorisk TLS for et domene uten å fikse videresendingen og verifisere sertifikatet for det er ineffektivt med tanke på sikkerhet og legger ikke til noe til de eksisterende STARTTLS-mekanismene.

Kilde: www.habr.com