Kort sagt är MTA-STS ett sätt att ytterligare skydda e-post från avlyssning (dvs. man-in-the-middle-attacker aka MitM) under överföring mellan e-postservrar. Det delvis löser de ärvda arkitekturproblem som finns med e-postprotokoll och beskrivs i den relativt nya standarden RFC 8461. Mail.ru är den första stora e-posttjänsten i Ryssland som implementerar denna standard. Mer detaljerad information finns under texten.

Vilket problem löser MTA-STS?

Historiskt sett har e-postprotokollen (SMTP, POP3, IMAP) överfört information i klartext, vilket gör det möjligt att avlyssna den, exempelvis via en säkerhetslucka i kommunikationskanalen.

Så här ser mekanismen för att leverera ett meddelande från en användare till en annan ut:

Historiskt sett har MitM-attacker varit möjliga vid alla punkter där e-post passerar.

Standard RFC 8314 kräver obligatorisk användning av TLS mellan användarens e-postprogram (MUA) och e-postservern. Om din server och de använda e-postapplikationerna följer RFC 8314 har du (i stor utsträckning) eliminerat möjligheten för man-in-the-middle-attacker mellan användaren och e-postservrarna.

Att följa allmänt vedertagna metoder (standardiserade RFC 8314) eliminerar attacker nära användaren:

Mail.ru:s e-postservrar har följt RFC 8314 redan innan standarden antogs, vilket innebär att det bara bekräftar redan etablerade metoder och vi behövde inte ställa in något ytterligare. Men om din e-postserver fortfarande tillåter användning av osäkra protokoll, se till att implementera rekommendationerna i denna standard, eftersom det troligtvis finns minst en del av dina användare som arbetar med e-post utan kryptering, även om du stödjer det.

E-postklienten arbetar alltid med en och samma e-postserver från samma organisation. Det är möjligt att påtvinga alla användare att koppla upp sig på ett säkert sätt, efter vilket det blir tekniskt omöjligt att ansluta osäkert (detta kräver just RFC 8314). Det kan ibland vara svårt, men är genomförbart. Med trafiken mellan e-postservrar är det ännu mer komplicerat. Servrarna tillhör olika organisationer och används ofta i ett "installera och glömma"-läge, vilket gör en samtidig övergång till ett säkert protokoll omöjlig utan att bryta kontinuiteten. Utökningsbara STARTTLS har funnits i SMTP under en lång tid, vilket tillåter servrar som stödjer kryptering att växla till TLS. Men en angripare som har möjlighet att påverka trafiken kan "klippa" information om stöd för detta kommando och tvinga servrarna att kommunicera via ett vanligt textprotokoll (så kallad nedgraderingsattack). Av samma anledning verifieras vanligtvis inte certifikat överensstämmelse för STARTTLS (ett otillförlitligt certifikat kan skydda mot passiva attacker, och det är inte sämre än att skicka ett meddelande i klartext). Därför skyddar STARTTLS endast mot passiv avlyssning.

MTA-STS delvis löser problemet med avlyssning av e-post mellan e-postservrar, när en angripare har möjlighet att aktivt påverka trafiken. Om mottagarens domän publicerar en MTA-STS-policy och avsändarens server stödjer MTA-STS, kommer den att skicka e-post endast över en TLS-anslutning, endast till servrar som anges i policyn och endast med certifikatverifiering av servern.

Varför delvis? MTA-STS fungerar endast om båda parter har säkerställt implementationen av denna standard och MTA-STS skyddar inte mot scenarier där en angripare har möjlighet att få ett giltigt domäncertifikat från en av de offentliga CA.

Hur fungerar MTA-STS

Mottagare

1. Konfigurerar stöd för STARTTLS med ett giltigt certifikat på e-postservern. 
2. Publicerar via HTTPS en MTA-STS-policy, för publiceringen används en speciell domän mta-sts och en speciell well-known sökväg, 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.
3. Publicerar en speciell TXT-post _mta-sts i DNS med policyns version. När policyn ändras måste denna post uppdateras (det signalerar till avsändaren att den behöver begära policyn på nytt). Till exempel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Afsender

Avsändaren begär DNS-posten _mta-sts, och om den finns görs en policyns begäran via HTTPS (som kontrollerar certifikatet). Den mottagna policyn cachas (ifall en angripare blockerar åtkomst till den eller manipulerar DNS-posten).

Vid e-postavsändning kontrolleras att:

• servern som e-posten levereras till finns i policyn;
• servern tar emot e-post med hjälp av 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). Ingen speciell mjukvarustöd krävs på mottagarens sida för att genomföra standarden.

Nackdelar med MTA-STS

Det är nödvändigt att övervaka giltigheten av certifikatet för webb- och e-postserver, namnens överensstämmelse och snabb uppdatering. Problem med certifikatet leder till att e-post inte kan levereras.

På avsändarens sida krävs en MTA som stödjer MTA-STS-policyer, för närvarande stöds MTA-STS inte "out-of-the-box" i MTA.

MTA-STS använder en lista över betrodda rot-CA.

MTA-STS skyddar inte mot attacker där en angripare använder ett giltigt certifikat. I de flesta fall innebär MitM i närheten av servern möjlighet att utfärda ett certifikat. En sådan attack kan upptäckas tack vare Certificate Transparency. Därför mildrar MTA-STS överlag men eliminerar inte helt möjligheten till trafikavlyssning.

De två senaste punkterna gör MTA-STS mindre skyddad än den konkurrerande standarden DANE för SMTP (RFC 7672), men mer tekniskt pålitlig, det vill säga att risken för att ett meddelande inte levereras på grund av tekniska problem orsakade av implementeringen av standarden är låg för MTA-STS.

Den konkurrerande standarden är DANE

DANE använder DNSSEC för att publicera information om certifikat och kräver inget förtroende för externa certifikatutfärdare, vilket är betydligt säkrare. Men användning av DNSSEC leder avsevärt oftare till tekniska fel, om man ser på statistiken från flera års användning (även om det finns en positiv trend i tillförlitligheten och det tekniska stödet för DNSSEC). För att implementera DANE i SMTP på mottagarens sida är det obligatoriskt med DNSSEC för DNS-zonen, och för DANE är det viktigt att korrekt stödja NSEC/NSEC3, där DNSSEC har systemproblem.

Om DNSSEC är felkonfigurerat kan det leda till avvisningar av e-post, om avsändarens sida stöder DANE, även om mottagarsidan inte vet något om det. Därför, trots att DANE är en äldre och säkrare standard som redan stöds i viss serverprogramvara på avsändarsidan, förblir dess genomslag litet, många organisationer är inte beredda att implementera det på grund av behovet av att genomföra DNSSEC, vilket har fördröjt införandet av DANE under de år som standarden har funnits.

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

Vad med MTA-STS-stödet i Mail.ru?

Mail.ru har länge publicerat MTA-STS-policies för alla stora domäner. Just nu arbetar vi med att implementera klientdelen av standarden. Vid tidpunkten för denna artikels skrivande tillämpas policyn i ett icke-blockerande läge (om leveransen blockeras av policyn kommer meddelandet att levereras via en "reserv"-server utan att följa policyn), och sedan kommer vi att tvinga in en blockerande läge för en liten del av den utgående SMTP-trafiken, gradvis kommer 100% av trafiken att stödja tillämpningen av policyn.

Vilka fler stöder standarden?

För närvarande publicerar ungefär 0.05% av aktiva domäner MTA-STS-policyn, men de skyddar redan en stor mängd e-posttrafik, eftersom stora aktörer som Google, Comcast och delvis Verizon (AOL, Yahoo) stöder standarden. Många andra e-posttjänster har meddelat att de kommer att implementera stödet för standarden inom en snar framtid.

Hur påverkar detta mig?

Inga, om din domän inte publicerar en MTA-STS-policy. Om du publicerar en policy blir e-postmeddelanden för användare på din e-postserver bättre skyddade mot avlyssning.

Hur implementerar jag MTA-STS?

MTA-STS-stöd på mottagarens sida

Det räcker med att publicera en policy via HTTPS och DNS-poster, konfigurera ett giltigt certifikat från en av de betrodda CA:erna (Let's Encrypt kan användas) för STARTTLS i MTA (STARTTLS stöds i alla moderna MTA:er), ingen särskild support från MTA behövs.

I steg ser det ut så här:

1. Konfigurera STARTTLS i den använda MTA:n (postfix, exim, sendmail, Microsoft Exchange, etc.).
2. Se till att ett giltigt certifikat används (utgivet av en betrodd CA, ogiltigt certifikat eller motsvarande objekt för certifikatet som stämmer överens med MX-posten för din domän).
3. Konfigurera en TLS-RPT-post där rapporter om policyernas tillämpning levereras (tjänster som stöder rapportutskick av TLS). Exempel på post (för domänen example.com):

   smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

   Denna post instruerar avsändare att skicka statistiska rapporter om användning av TLS i SMTP till adressen tlsrpt@exmple.com.

   Håll koll på rapporterna några dagar, se till att det inte finns några fel.

4. Publicera MTA-STS-policyn via HTTPS. Policyn publiceras som en textfil med CRLF radavslutare på angiven plats.

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   Exempel på policy:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   Fältet version innehåller policyversionen (just nu är det STSv1), mode anger tillämpningsläge för policyn, testing — testläge (policyn tillämpas inte), enforce — "standardläge". Publicera först policyn med mode: testing, om det inte finns några problem med policyn i testläget, kan du efter ett tag växla till mode: enforce.

   I mx anges en lista över alla e-postservrar som kan ta emot e-post för din domän (varje server måste ha ett certifikat som motsvarar namnet som anges i mx). Max_age anger tiden för cachelagring av policyn (en gång inläst kommer policyn att tillämpas även om en angripare blockerar dess avlämning eller gör DNS-posterna ogiltiga under cachelagringstiden, signal om att policyn måste begäras på nytt kan ges genom att ändra mta-sts-posten i DNS).

5. Publicera en TXT-post i DNS: 

   _mta-sts.example.com. TXT "v=STS1; id=someid;"
   

   I fältet id kan en godtycklig identifierare (t.ex. tidsstämpel) användas, och vid förändring av policyn måste den ändras. Detta gör det möjligt för avsändarna att förstå att den cachade policyn måste begäras på nytt (om identifieraren skiljer sig från den cachade).

Stöd för MTA-STS på avsändarsidan

Det går fortfarande dåligt med det, eftersom standarden är ny.

• Exim — ingen inbyggd support, det finns ett tredjeparts skript https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix — ingen inbyggd support, det finns ett tredjeparts skript som beskrivs i detalj på Habr. https://habr.com/en/post/424961/

Som en slutkommentar om "mandatory TLS"

Nyligen har reglerare börjat fokusera på säkerheten inom e-post (och det är bra). Till exempel är DMARC obligatoriskt för alla statliga institutioner i USA och blir allt oftare ett krav inom finanssektorn; i reglerade områden når standardens genomslag 90%. Vissa reglerare kräver nu implementering av "mandatory TLS" med särskilda domäner, men mekanismen för att säkerställa "mandatory TLS" definieras inte, och i praktiken implementeras denna inställning ofta på ett sätt som minimalt skyddar mot verkliga attacker, som redan beaktas i mekanismer som DANE eller MTA-STS.

Om regleraren kräver implementering av "mandatory TLS" med särskilda 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 individuellt. Om du har problem med att implementera klientdelen av MTA-STS (tills protokollet får bred support, kommer det förmodligen att uppstå), kan ett sådant tillvägagångssätt rekommenderas:

1. Publicera MTA-STS policyn och/eller DANE-poster (DANE har mening att lägga till endast om DNSSEC redan är aktiverat för din domän, samt MTA-STS i alla fall). Detta skyddar trafiken mot din sida och eliminerar behovet av att be andra e-posttjänster att ställa in mandatory TLS för din domän, om e-posttjänsten redan stöder MTA-STS och/eller DANE.
2. För stora e-posttjänster implementera en "analog" till MTA-STS genom separata transportinställningar för varje domän, som fastställer den MX som används för e-postrelay och som kommer att kräva obligatorisk verifiering av TLS-certifikatet. Om domäner redan publicerar en MTA-STS-policy, kan detta troligtvis göras utan problem. Att enbart aktivera obligatorisk TLS för en domän utan att fastställa reläet och verifiera certifikatet är ineffektivt ur säkerhetssynpunkt och tillför inget till de befintliga STARTTLS-mekanismerna.

Källa: habr.com