Kort sagt, MTA-STS er en måte å ytterligere beskytte e-poster mot avskjæring (dvs. man-in-the-middle-angrep aka MitM) når de overføres mellom e-postservere. Den løser delvis de eldre arkitektoniske problemene til e-postprotokoller og er beskrevet i den relativt nye standarden RFC 8461. Mail.ru er den første store e-posttjenesten på RuNet som implementerer denne standarden. Og det er beskrevet mer detaljert under kuttet.

Hvilket problem løser MTA-STS?

Historisk har e-postprotokoller (SMTP, POP3, IMAP) overført informasjon i klartekst, noe som gjorde det mulig å avskjære den, for eksempel ved tilgang til en kommunikasjonskanal.

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

Historisk sett var et MitM-angrep mulig alle steder der post sirkulerer.

RFC 8314 krever bruk av TLS mellom e-postbrukerapplikasjonen (MUA) og e-postserveren. Hvis serveren din og e-postapplikasjonene du bruker er kompatible med RFC 8314, har du (stort sett) eliminert muligheten for Man-in-the-Middle-angrep mellom brukeren og e-postserverne.

Å følge generelt akseptert praksis (standardisert av RFC 8314) eliminerer angrepet nær brukeren:

Mail.ru e-postservere overholdt RFC 8314 selv før standarden ble tatt i bruk; faktisk fanger den ganske enkelt opp allerede akseptert praksis, og vi trengte ikke å konfigurere noe ekstra. Men hvis e-postserveren din fortsatt tillater brukere å bruke usikre protokoller, sørg for å implementere anbefalingene i denne standarden, fordi Mest sannsynlig jobber i det minste noen av brukerne dine med e-post uten kryptering, selv om du støtter det.

E-postklienten fungerer alltid med den samme e-postserveren til samme organisasjon. Og du kan tvinge alle brukere til å koble til på en sikker måte, og deretter gjøre det teknisk umulig for ikke-sikre brukere å koble til (dette er nøyaktig hva RFC 8314 krever). Dette er noen ganger vanskelig, men gjennomførbart. Trafikk mellom e-postservere er fortsatt mer komplisert. Servere tilhører forskjellige organisasjoner og brukes ofte i en "sett og glem"-modus, noe som gjør det umulig å bytte til en sikker protokoll på en gang uten å bryte tilkoblingen. SMTP har lenge levert STARTTLS-utvidelsen, 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 serverne til å kommunisere ved hjelp av en ren tekstprotokoll (det såkalte nedgraderingsangrepet). Av samme grunn sjekker STARTTLS vanligvis ikke gyldigheten av sertifikatet (et uklarert sertifikat kan beskytte mot passive angrep, og dette er ikke verre enn å sende en melding i klartekst). Derfor beskytter STARTTLS kun mot passiv avlytting.

MTA-STS eliminerer delvis problemet med å avskjære 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 kun sende e-posten over en TLS-tilkobling, kun til servere definert av policyen, og kun med verifisering av serverens sertifikat.

Hvorfor delvis? MTA-STS fungerer bare hvis begge parter har tatt vare på å implementere denne standarden, og MTA-STS beskytter ikke mot scenarier der en angriper kan få et gyldig domene-sertifikat 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-policyen via HTTPS; et spesielt mta-sts-domene og en spesiell velkjent sti brukes for publisering, for eksempel https://mta-sts.mail.ru/.well-known/mta-sts.txt. Policyen inneholder en liste over e-postservere (mx) som har rett til å motta e-post for dette domenet.
Publiserer en spesiell TXT-post _mta-sts i DNS med policyversjonen. Når policyen endres, må denne oppføringen oppdateres (dette signaliserer at avsenderen skal spørre policyen på nytt). For eksempel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Avsender

Avsenderen ber om _mta-sts DNS-posten, og hvis den er tilgjengelig, foretar en policyforespørsel via HTTPS (sjekker sertifikatet). Den resulterende policyen bufres (i tilfelle en angriper blokkerer tilgang til den eller forfalsker DNS-posten).

При отправке почты, проверяется что:

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

Fordeler med MTA-STS

MTA-STS использует технологии, которые уже внедрены в большинстве организаций (SMTP+STARTTLS, HTTPS, DNS). Для реализации на стороне получателя не требуется специальной программной поддержки стандарта.

Ulemper med MTA-STS

Необходимо следить за валидностью сертификата веб и почтового сервера, соответствием имен, своевременным обновлением. Проблемы с сертификатом приведут к невозможности доставить почту.

På avsendersiden kreves det en MTA med støtte for MTA-STS-policyer; for øyeblikket støttes ikke MTA-STS ut av boksen i MTA.

MTA-STS bruker en liste over pålitelige rot-CAer.

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

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

Konkurrerende standard - DANSK

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

Hvis DNSSEC ikke er riktig konfigurert, kan det resultere i postleveringsfeil hvis avsendersiden støtter DANE, selv om mottakersiden ikke vet noe om det. Derfor, til tross for at DANE er en eldre og sikrere standard og allerede støttes i noen serverprogramvare på avsendersiden, er penetrasjonen faktisk 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 de årene standarden har eksistert.

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

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

Mail.ru har publisert en MTA-STS-policy for alle større domener i ganske lang tid. Vi implementerer for tiden klientdelen av standarden. I skrivende stund brukes retningslinjer i en ikke-blokkerende modus (hvis levering blokkeres av en policy, vil brevet bli levert gjennom en "reserve"-server uten å bruke retningslinjer), deretter vil blokkeringsmodus tvinges til en liten del av utgående SMTP-trafikk, vil det gradvis for 100 % av trafikken bli Håndhevelse av retningslinjer støttes.

Hvem andre støtter standarden?

Så langt publiserer MTA-STS-policyer omtrent 0.05 % av aktive domener, men likevel beskytter de allerede et stort volum av e-posttrafikk, fordi Standarden støttes av store aktører – Google, Comcast og delvis Verizon (AOL, Yahoo). Mange andre posttjenester har varslet at støtte for standarden vil bli implementert i nær fremtid.

Hvordan vil dette påvirke meg?

Ikke med mindre domenet ditt publiserer en MTA-STS-policy. Hvis du publiserer retningslinjene, vil e-poster for brukere av e-postserveren 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 poster i DNS, konfigurere et gyldig sertifikat fra en av de pålitelige CA-ene (La oss kryptere er mulig) for STARTTLS i MTA (STARTTLS støttes i alle moderne MTA-er), ingen spesiell støtte fra MTA kreves.

Steg for steg ser det slik ut:

Konfigurer STARTTLS i MTAen du bruker (postfix, exim, sendmail, Microsoft Exchange, etc.).
Sørg for at du bruker et gyldig sertifikat (utstedt av en klarert CA, ikke utløpt, emnet for sertifikatet samsvarer med MX-posten som leverer e-post for domenet ditt).
Konfigurer en TLS-RPT-post gjennom hvilken policyapplikasjonsrapporter skal leveres (av tjenester som støtter sending av TLS-rapporter). Eksempeloppføring (for domenet example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Denne oppføringen instruerer e-postavsendere om å sende statistiske rapporter om TLS-bruk i SMTP til [email protected].

Overvåk rapportene i flere dager for å sikre at det ikke er noen feil.
Publiser MTA-STS-policyen over HTTPS. Policyen er publisert som en tekstfil med CRLF-linjeterminatorer etter plassering.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Eksempel på retningslinjer:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Versjonsfeltet inneholder versjonen av policyen (for øyeblikket STSv1), Mode setter policyapplikasjonsmodus, testing - testmodus (policyen brukes ikke), håndheve - "combat"-modus. Publiser først policyen med modus: testing, hvis det ikke er problemer med policyen i testmodus, kan du etter en stund bytte til modus: håndheve.

I mx er en liste over alle e-postservere som kan akseptere e-post for ditt domene spesifisert (hver server må ha et sertifikat konfigurert som samsvarer med navnet spesifisert i mx). Max_age spesifiserer hurtigbufringstiden for policyen (når den huskede policyen blir brukt selv om angriperen blokkerer leveringen eller ødelegger DNS-postene i løpet av bufringstiden, kan du signalisere behovet for å be om policyen på nytt ved å endre mta-sts DNS ta opp).
Publiser en TXT-post i DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
En vilkårlig identifikator (for eksempel et tidsstempel) kan brukes i id-feltet; når policyen endres, bør den endres, dette lar avsendere forstå at de må be om den bufrede policyen på nytt (hvis identifikatoren er forskjellig fra bufret en).

MTA-STS-støtte på avsendersiden

Så langt er det dårlig med henne, fordi... fersk standard.

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

Som et etterord om "obligatorisk TLS"

I det siste har regulatorer vært oppmerksomme på e-postsikkerhet (og det er en god ting). For eksempel er DMARC obligatorisk for alle offentlige etater i USA og er i økende grad påkrevd i finanssektoren, med penetrasjon av standarden som når 90 % i regulerte områder. Nå krever noen regulatorer 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 forutsatt i mekanismer som DANE eller MTA-STS.

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

Publiser en MTA-STS-policy og/eller DANE-poster (DANE gir mening bare hvis DNSSEC allerede er aktivert for domenet ditt, og MTA-STS i alle fall), dette vil beskytte trafikk i din retning og eliminere behovet for å spørre andre e-posttjenester for å konfigurere obligatorisk TLS for ditt domene 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, som vil fikse MX-en som brukes for e-postoverføring og vil kreve obligatorisk verifisering av et TLS-sertifikat for det. Hvis domenene allerede publiserer en MTA-STS-policy, kan dette sannsynligvis gjøres smertefritt. Å aktivere obligatorisk TLS for et domene uten å fikse reléet og bekrefte sertifikatet for det er i seg selv ineffektivt fra et sikkerhetssynspunkt og legger ikke til noe til de eksisterende STARTTLS-mekanismene.

Kilde: www.habr.com

Mail.ru-post begynner å bruke MTA-STS-policyer i testmodus