Kort sagt, MTA-STS är ett sätt att ytterligare skydda e-post från avlyssning (dvs man-i-mitten-attacker aka MitM) när de överförs mellan e-postservrar. Det löser delvis de gamla arkitektoniska problemen med e-postprotokoll och beskrivs i den relativt nya standarden RFC 8461. Mail.ru är den första stora e-posttjänsten på RuNet som implementerar denna standard. Och det beskrivs mer detaljerat under snittet.

Vilket problem löser MTA-STS?

Historiskt har e-postprotokoll (SMTP, POP3, IMAP) överfört information i klartext, vilket gjorde det möjligt att avlyssna den, till exempel vid åtkomst till en kommunikationskanal.

Hur ser mekanismen för att leverera ett brev från en användare till en annan ut:

Historiskt sett var en MitM-attack möjlig på alla platser där post cirkulerar.

RFC 8314 kräver användning av TLS mellan e-postanvändarapplikationen (MUA) och e-postservern. Om din server och e-postapplikationerna du använder är kompatibla med RFC 8314, har du (i stort sett) eliminerat möjligheten för Man-in-the-Middle-attacker mellan användaren och e-postservrarna.

Att följa allmänt accepterad praxis (standardiserad av RFC 8314) eliminerar attacken nära användaren:

Mail.ru e-postservrar överensstämde med RFC 8314 redan innan standarden antogs; i själva verket fångar den helt enkelt redan accepterad praxis, och vi behövde inte konfigurera något ytterligare. Men om din e-postserver fortfarande tillåter användare att använda osäkra protokoll, se till att implementera rekommendationerna i denna standard, eftersom Troligtvis arbetar åtminstone några av dina användare med e-post utan kryptering, även om du stöder det.

E-postklienten arbetar alltid med samma e-postserver i samma organisation. Och du kan tvinga alla användare att ansluta på ett säkert sätt och sedan göra det tekniskt omöjligt för icke-säkra användare att ansluta (det är precis vad RFC 8314 kräver). Detta är ibland svårt, men genomförbart. Trafiken mellan e-postservrar är fortfarande mer komplicerad. Servrar tillhör olika organisationer och används ofta i ett "ställ in och glöm"-läge, vilket gör det omöjligt att byta till ett säkert protokoll på en gång utan att bryta anslutningen. SMTP har länge tillhandahållit tillägget STARTTLS, som gör att servrar som stöder kryptering kan byta till TLS. Men en angripare som har förmågan att påverka trafiken kan "klippa ut" information om stöd för detta kommando och tvinga servrarna att kommunicera med ett vanlig textprotokoll (den så kallade nedgraderingsattacken). Av samma anledning kontrollerar STARTTLS vanligtvis inte certifikatets giltighet (ett opålitligt certifikat kan skydda mot passiva attacker, och det är inte värre än att skicka ett meddelande i klartext). Därför skyddar STARTTLS endast mot passiv avlyssning.

MTA-STS eliminerar delvis problemet med att fånga upp brev mellan e-postservrar, när angriparen har möjlighet att aktivt påverka trafiken. Om mottagarens domän publicerar en MTA-STS-policy och avsändarens server stöder MTA-STS, kommer den endast att skicka e-postmeddelandet via en TLS-anslutning, endast till servrar som definieras av policyn, och endast med verifiering av serverns certifikat.

Varför delvis? MTA-STS fungerar bara om båda parter har sett till att implementera denna standard, och MTA-STS skyddar inte mot scenarier där en angripare kan få ett giltigt domäncertifikat från en av de offentliga CA:erna.

Hur MTA-STS fungerar

mottagare

Konfigurerar STARTTLS-stöd med ett giltigt certifikat på e-postservern.
Publicerar MTA-STS-policyn via HTTPS; en speciell mta-sts-domän och en speciell välkänd sökväg används för publicering, till exempel https://mta-sts.mail.ru/.well-known/mta-sts.txt. Policyn innehåller en lista över e-postservrar (mx) som har rätt att ta emot e-post för denna domän.
Publicerar en speciell TXT-post _mta-sts i DNS med policyversionen. När policyn ändras måste denna post uppdateras (detta signalerar avsändaren att fråga om policyn igen). Till exempel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Avsändare

Avsändaren begär _mta-sts DNS-posten, och om den är tillgänglig, gör en policybegäran via HTTPS (kontrollerar certifikatet). Den resulterande policyn cachelagras (i fall en angripare blockerar åtkomst till den eller förfalskar DNS-posten).

När du skickar e-post är det kontrollerat att:

servern till vilken e-post levereras finns i policyn;
servern accepterar e-post med TLS (STARTTLS) och har ett giltigt certifikat.

Fördelar med MTA-STS

MTA-STS använder teknologier som redan är implementerade i de flesta organisationer (SMTP+STARTTLS, HTTPS, DNS). För implementering på mottagarsidan krävs inget särskilt mjukvarustöd för standarden.

Nackdelar med MTA-STS

Det är nödvändigt att övervaka giltigheten av webb- och e-postservercertifikatet, namnens överensstämmelse och förnyelse i tid. Problem med certifikatet kommer att resultera i att post inte kan levereras.

På avsändarsidan krävs en MTA med stöd för MTA-STS-policyer, för närvarande stöds inte MTA-STS direkt i MTA.

MTA-STS använder en lista över betrodda rotcertifikatutfärdare.

MTA-STS skyddar inte mot attacker där angriparen använder ett giltigt certifikat. I de flesta fall innebär MitM nära servern möjligheten att utfärda ett certifikat. En sådan attack kan upptäckas med Certificate Transparency. Därför mildrar MTA-STS i allmänhet, men eliminerar inte helt, möjligheten till trafikavlyssning.

De två sista punkterna gör MTA-STS mindre säker än den konkurrerande DANE-standarden för SMTP (RFC 7672), men mer tekniskt tillförlitlig, d.v.s. för MTA-STS är sannolikheten låg att brevet inte kommer att levereras på grund av tekniska problem orsakade av implementeringen av standarden.

Tävlande standard - DANE

DANE använder DNSSEC för att publicera certifikatinformation och kräver inget förtroende för externa certifikatutfärdare, vilket är mycket säkrare. Men användningen av DNSSEC leder betydligt oftare till tekniska fel, baserat på statistik över flera års användning (även om det generellt finns en positiv trend i tillförlitligheten av DNSSEC och dess tekniska support). För att implementera DANE i SMTP på mottagarsidan är närvaron av DNSSEC för DNS-zonen obligatorisk, och korrekt stöd för NSEC/NSEC3 är väsentligt för DANE, med vilka det finns systemproblem i DNSSEC.

Om DNSSEC inte är korrekt konfigurerat kan det resultera i e-postleveransfel om den sändande sidan stöder DANE, även om den mottagande sidan inte vet något om det. Därför, trots det faktum att DANE är en äldre och säkrare standard och redan stöds i viss serverprogramvara på avsändarsidan, i själva verket förblir dess penetration obetydlig, många organisationer är inte redo att implementera den på grund av behovet av att implementera DNSSEC, detta har avsevärt bromsat införandet av DANE under de år som standarden har funnits.

DANE och MTA-STS kommer inte i konflikt med varandra och kan användas tillsammans.

Vad är det för MTA-STS-stöd i Mail.ru Mail?

Mail.ru har publicerat en MTA-STS-policy för alla större domäner under ganska lång tid. Vi implementerar just nu kunddelen av standarden. I skrivande stund tillämpas policyer i ett icke-blockerande läge (om leverans blockeras av en policy kommer brevet att levereras via en "reserv" server utan att tillämpa policyer), då kommer blockeringsläget att tvingas till en liten del av utgående SMTP-trafik, gradvis för 100 % av trafiken kommer det att vara Upprätthållande av policyer stöds.

Vem mer stödjer standarden?

Hittills publicerar MTA-STS-policyer cirka 0.05 % av de aktiva domänerna, men ändå skyddar de redan en stor volym e-posttrafik, eftersom Standarden stöds av stora aktörer – Google, Comcast och delvis Verizon (AOL, Yahoo). Många andra posttjänster har meddelat att stöd för standarden kommer att implementeras inom en snar framtid.

Hur kommer detta att påverka mig?

Inte om din domän publicerar en MTA-STS-policy. Om du publicerar policyn kommer e-postmeddelanden för användare av din e-postserver att vara bättre skyddade från avlyssning.

Hur implementerar jag MTA-STS?

MTA-STS-stöd på mottagarsidan

Det räcker med att publicera policyn via HTTPS och poster i DNS, konfigurera ett giltigt certifikat från en av de betrodda CA:erna (Låt oss kryptera är möjligt) för STARTTLS i MTA (STARTTLS stöds i alla moderna MTAs), inget särskilt stöd från MTA krävs.

Steg för steg ser det ut så här:

Konfigurera STARTTLS i den MTA du använder (postfix, exim, sendmail, Microsoft Exchange, etc.).
Se till att du använder ett giltigt certifikat (utfärdat av en betrodd certifikatutfärdare, inte utgånget, ämnet för certifikatet matchar MX-posten som levererar e-post för din domän).
Konfigurera en TLS-RPT-post genom vilken policyapplikationsrapporter kommer att levereras (av tjänster som stöder sändning av TLS-rapporter). Exempelpost (för domänen example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Den här posten instruerar e-postavsändare att skicka statistiska rapporter om TLS-användning i SMTP till [email protected].

Övervaka rapporterna i flera dagar för att se till att det inte finns några fel.
Publicera MTA-STS-policyn över HTTPS. Policyn publiceras som en textfil med CRLF-linjeavslutare efter plats.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Exempelpolicy:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Versionsfältet innehåller versionen av policyn (för närvarande STSv1), Mode ställer in policyapplikationsläget, testning - testläge (policyn tillämpas inte), verkställ - "stridsläge". Publicera först policyn med mode: testing, om det inte finns några problem med policyn i testläge kan du efter ett tag byta till mode: enforce.

I mx anges en lista över alla e-postservrar som kan acceptera e-post för din domän (varje server måste ha ett certifikat konfigurerat som matchar namnet som anges i mx). Max_age anger cachningstiden för policyn (när den ihågkomna policyn kommer att tillämpas även om angriparen blockerar dess leverans eller korrumperar DNS-posterna under cachningstiden, kan du signalera behovet av att begära policyn igen genom att ändra mta-sts DNS spela in).
Publicera en TXT-post i DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
En godtycklig identifierare (till exempel en tidsstämpel) kan användas i id-fältet; när policyn ändras bör den ändras, vilket gör att avsändare kan förstå att de behöver begära den cachade policyn på nytt (om identifieraren skiljer sig från cachade en).

MTA-STS-stöd på avsändarsidan

Än så länge är det dåligt med henne, för... fräsch standard.

Exim - inget inbyggt stöd, det finns ett tredjepartsskript https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - det finns inget inbyggt stöd, det finns ett tredjepartsskript som beskrivs i detalj på Habré https://habr.com/en/post/424961/

Som ett efterord om "obligatorisk TLS"

På senare tid har tillsynsmyndigheter uppmärksammat e-postsäkerhet (och det är bra). DMARC är till exempel obligatoriskt för alla statliga myndigheter i USA och krävs alltmer inom finanssektorn, med penetration av standarden som når 90 % i reglerade områden. Nu kräver vissa tillsynsmyndigheter implementering av "obligatorisk TLS" med individuella domäner, men mekanismen för att säkerställa "obligatorisk TLS" är inte definierad och i praktiken implementeras denna inställning ofta på ett sätt som inte ens minimalt skyddar mot verkliga attacker som redan är tillhandahålls i mekanismer som DANE eller MTA-STS.

Om regulatorn kräver implementering av "obligatorisk TLS" med separata domäner, rekommenderar vi att överväga MTA-STS eller dess partiella analog som den mest lämpliga mekanismen, det eliminerar behovet av att göra säkra inställningar för varje domän separat. Om du har problem med att implementera klientdelen av MTA-STS (tills protokollet har fått brett stöd, kommer de troligen att göra det), kan vi rekommendera detta tillvägagångssätt:

Publicera en MTA-STS-policy och/eller DANE-poster (DANE är bara vettigt om DNSSEC redan är aktiverat för din domän, och MTA-STS i alla fall), detta kommer att skydda trafiken i din riktning och eliminera behovet av att fråga andra e-posttjänster för att konfigurera obligatorisk TLS för din domän om e-posttjänsten redan stöder MTA-STS och/eller DANE.
För stora e-posttjänster, implementera en "analog" av MTA-STS genom separata transportinställningar för varje domän, vilket kommer att fixa MX som används för e-postöverföring och kommer att kräva obligatorisk verifiering av ett TLS-certifikat för det. Om domänerna redan publicerar en MTA-STS-policy kan detta sannolikt göras smärtfritt. Att aktivera obligatorisk TLS för en domän utan att fixa reläet och verifiera certifikatet för det är i sig ineffektivt ur säkerhetssynpunkt och tillför ingenting till de befintliga STARTTLS-mekanismerna.

Källa: will.com

Mail.ru mail börjar tillämpa MTA-STS-policyer i testläge