Pokud to shrneme, MTA-STS je způsob, jak dále chránit e-maily před zachycením (tj. útoky typu muž uprostřed, aka MitM) při přenosu mezi poštovními servery. Částečně řeší zděděné architektonické problémy e-mailových protokolů a je popsán v relativně novém standardu RFC 8461. Mail.ru je první velká poštovní služba v Ruském internetu, která implementovala tento standard. Podrobněji se o tom hovoří níže.

Jaký problém MTA-STS řeší?

Historicky e-mailové protokoly (SMTP, POP3, IMAP) přenášely informace v nezabezpečené podobě, což umožňuje jejich zachycení, například při přístupu k komunikačnímu kanálu.

Jak vypadá mechanismus doručení e-mailu od jednoho uživatele k druhému:

Historicky bylo možné útoky MitM provádět na všech místech, kde prochází e-mail.

Standard RFC 8314 vyžaduje povinné používání TLS mezi poštovním klientem uživatele (MUA) a poštovním serverem. Pokud váš server a používané poštovní aplikace splňují RFC 8314, pak jste (do značné míry) eliminovali možnost útoků typu muž uprostřed mezi uživateli a poštovními servery.

Dodržování běžně uznávaných praktik (standardizovaných RFC 8314) eliminuje útoky v blízkosti uživatele:

Poštovní servery Mail.ru splnily RFC 8314 již před jeho přijetím, ve skutečnosti pouze zaznamenává již přijaté praktiky a nemuseli jsme nic nastavovat navíc. Pokud však váš poštovní server stále povoluje uživatelům používání nezabezpečených protokolů, určitě implementujte doporučení tohoto standardu, protože pravděpodobně alespoň část vašich uživatelů pracuje s e-mailem bez šifrování, i když jej podporujete.

Poštovní klient vždy pracuje s jedním a tím samým poštovním serverem jedné a téže organizace. A lze donutit všechny uživatele, aby se připojovali bezpečným způsobem, přičemž se pak stane technicky nemožným připojit se nezabezpečeným způsobem (to je přesně to, co požaduje RFC 8314). Někdy je to obtížné, ale realizovatelné. S provozem mezi poštovními servery je to ještě složitější. Servery patří různým organizacím a často se používají v režimu „nainstaluj a zapomeň“, což znemožňuje jednorázové přepnutí na bezpečný protokol bez narušení spojení. V protokolu SMTP je již delší dobu k dispozici rozšíření STARTTLS, které umožňuje serverům podporujícím šifrování přepnout na TLS. Ale útočník, který má možnost ovlivnit provoz, může „vykrojit“ informace o podpoře tohoto příkazu a přinutit servery, aby komunikovaly prostřednictvím běžného textového protokolu (tzv. downgrade attack – útok na snížení verze protokolu). Z toho důvodu se pro STARTTLS obvykle neověřuje shoda certifikátu (nedůvěryhodný certifikát může chránit před pasivními útoky a je to lepší než odesílání zprávy v otevřeném textu). Proto STARTTLS chrání pouze před pasivním odposloucháváním.

MTA-STS částečně řeší problém odposlechu zpráv mezi poštovními servery, když má útočník možnost aktivně ovlivnit provoz. Pokud doména příjemce publikuje politiku MTA-STS a server odesílatele podporuje MTA-STS, bude zpráva odeslána pouze prostřednictvím TLS připojení, pouze na servery určené politikou a pouze s ověřením certifikátu serveru.

Proč částečně? MTA-STS funguje pouze tehdy, když obě strany dbají na implementaci tohoto standardu, a MTA-STS nechrání před scénáři, ve kterých má útočník možnost získat platný certifikát domény v jednom z veřejných CA.

Jak funguje MTA-STS

Příjemce

1. Nastavuje podporu STARTTLS s platným certifikátem na poštovním serveru. 
2. Publikuje prostřednictvím HTTPS politiku MTA-STS, pro publikaci se používá speciální doména mta-sts a speciální well-known cesta, například https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika obsahuje seznam poštovních serverů (mx), které mají právo přijímat poštu pro tuto doménu.
3. Publikuje speciální TXT záznam _mta-sts v DNS s verzí politiky. Při změně politiky by tento záznam měl být aktualizován (což signalizuje odesílateli, že je třeba znovu požádat o politiku). Například, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Odesílatel

Odesílatel požaduje DNS záznam _mta-sts, a pokud existuje, provádí dotaz na politiku přes HTTPS (ověřuje certifikát). Získaná politika se uchovává v cache (pro případ, že útočník zablokuje přístup k ní nebo podvrhne DNS záznam).

Při odesílání emailu se kontroluje, že:

• server, na který je email doručován, je v politice;
• server přijímá email s použitím TLS (STARTTLS) a má platný certifikát.

Výhody MTA-STS

MTA-STS využívá technologie, které jsou již implementovány ve většině organizací (SMTP+STARTTLS, HTTPS, DNS). Pro implementaci na straně příjemce není vyžadována speciální softwarová podpora standardu.

Nevýhody MTA-STS

Je třeba dbát na platnost certifikátu webového a poštovního serveru, souladu názvů a včasnou aktualizaci. Problémy s certifikátem povedou k neschopnosti doručit email.

Na straně odesílatele je vyžadováno MTA s podporou politik MTA-STS, v současné době MTA-STS není nativně podporováno v MTA.

MTA-STS využívá seznam důvěryhodných kořenových CA.

MTA-STS nechrání před útoky, při kterých útočník používá platný certifikát. Ve většině případů MitM blízko serveru znamená možnost vydání certifikátu. Takový útok může být odhalen díky Certificate Transparency. Proto celkově MTA-STS zmírňuje, ale neodstraňuje úplně možnost odposlechu provozu.

Dva poslední body činí MTA-STS méně chráněným než konkurenční standard DANE pro SMTP (RFC 7672), ale technicky spolehlivějším, t.j. pro MTA-STS je nízká pravděpodobnost, že email nebude doručen kvůli technickým problémům způsobeným implementací standardu.

Konkurenční standard — DANE

DANE používá DNSSEC k publikaci informací o certifikátech a nevyžaduje důvěru v externí certifikační autority, což je mnohem bezpečnější. Nicméně používání DNSSEC často vede k technickým problémům, pokud se spoléháme na statistiky za několik let používání (přestože v oblasti spolehlivosti DNSSEC a jeho technické podpory celkově pozorujeme pozitivní trend). Pro implementaci DANE v SMTP na straně příjemce je nutné mít DNSSEC pro DNS zónu, přičemž pro DANE je klíčová správná podpora NSEC/NSEC3, s níž má DNSSEC systémové problémy.

Pokud je DNSSEC nakonfigurováno chybně, může to vést k odmítnutí dodání e-mailů, pokud odesílající strana podporuje DANE, i když příjemce o něm nic neví. Proto, i když je DANE starší a bezpečnější standard již podporovaný v některém serverovém softwaru na straně odesílatele, jeho nasazení zůstává zatím nevýznamné. Mnoho organizací není připraveno ho zavádět kvůli nutnosti implementace DNSSEC, což značně brzdilo přijetí DANE po celou dobu existence standardu.

DANE a MTA-STS si navzájem neodporují a mohou být používány společně.

Jak je to s podporou MTA-STS v Mail.ru?

Mail.ru již dost dlouho publikuje politiku MTA-STS pro všechny hlavní domény. Nyní se zabýváme implementací klientské části standardu. V době psaní tohoto článku jsou politiky uplatňovány v neblokujícím režimu (pokud je doručení blokováno politikou, e-mail bude dodán prostřednictvím "náhradního" serveru bez použití politik), poté bude vynucen blokující režim pro malou část odchozího SMTP provozu, který postupně podpoří použití politik pro 100% provozu.

Kdo další podporuje standard?

V současnosti publikuje politiky MTA-STS přibližně 0,05 % aktivních domén, přesto však už chrání velké objemy e-mailového provozu, protože standard podporují velcí hráči — Google, Comcast a částečně Verizon (AOL, Yahoo). Mnoho dalších e-mailových služeb oznámilo, že podpora standardu bude realizována v blízké budoucnosti.

Jak se to dotkne mě?

Nicoliv, pokud váš doménový server nepublikuje politiku MTA-STS. Pokud politiku publikujete, budou e-maily pro uživatele vašeho poštovního serveru lépe chráněny před odposlechem.

Jak implementovat MTA-STS?

Podpora MTA-STS na straně příjemce

Stačí publikovat politiku prostřednictvím HTTPS a záznamů v DNS, nastavit platný certifikát od jednoho z důvěryhodných CA (můžete použít Let’s Encrypt) pro STARTTLS v MTA (STARTTLS podporují všechny moderní MTA), speciální podpora ze strany MTA není potřebná.

Po krocích to vypadá takto:

1. Nastavte STARTTLS ve vašem používaném MTA (postfix, exim, sendmail, Microsoft Exchange atd.).
2. Ujistěte se, že je použit platný certifikát (vydaný důvěryhodným CA, neprošlý, subjekt certifikátu odpovídá MX záznamu, podle kterého je doručována pošta pro vaši doménu).
3. Nastavte záznam TLS-RPT, na který budou zasílány zprávy o použití politiky (službami podporujícími zasílání zpráv TLS). Příklad záznamu (pro doménu example.com):

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

   Tento záznam instruuje odesílatele e-mailů, aby zasílali statistické zprávy o použití TLS v SMTP na adresu tlsrpt@exmple.com.

   Sledujte zprávy několik dní, ujistěte se, že nejsou žádné chyby.

4. Publikujte politiku MTA-STS prostřednictvím HTTPS. Politika se publikuje jako textový soubor s ukončujícími znaky CRLF na umístění.

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

   Příklad politiky:

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

   Pole version obsahuje verzi politiky (nyní je to STSv1), Mode určuje režim použití politiky, testing — testovací režim (politika se neuplatňuje), enforce — "produkční" režim. Nejprve publikujte politiku s mode: testing, pokud s politikou nebudou problémy v testovacím režimu, po určitém čase se můžete přepnout na mode: enforce.

   V mx je uveden seznam všech poštovních serverů, které mohou přijímat poštu pro vaši doménu (u každého serveru musí být nastaven certifikát odpovídající názvu uvedenému v mx). Max_age určuje dobu kešování politiky (jednou zapamatovaná politika bude aplikována, i když útočník zablokuje její vydání nebo poškodí DNS záznamy během doby kešování, signál k opětovnému dotazu na politiku lze zaslat změnou mta-sts záznamu v DNS).

5. Publikujte v DNS TXT záznam: 

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

   V poli id lze použít libovolný identifikátor (například časovou značku), při změně politiky by se měl měnit, což umožňuje odesílatelům pochopit, že je třeba znovu načíst mezipaměť politiky (pokud se identifikátor liší od mezipaměti).

Podpora MTA-STS na straně odesílatele

Zatím to není dobré, protože standard je nový.

• Exim — nemá vestavěnou podporu, existuje externí skript https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix — nemá vestavěnou podporu, je zde externí skript, o kterém je podrobně napsáno na Habru https://habr.com/en/post/424961/

Na závěr o «mandatory TLS»

V poslední době se regulátoři zaměřují na bezpečnost e-mailu (a to je dobré). Například DMARC je povinný pro všechny státní instituce v USA a stále častěji je vyžadován v oblasti financí, v regulovaných odvětvích dosahuje zavedení standardu 90%. Někteří regulátoři nyní vyžadují zavedení «mandatory TLS» pro jednotlivé domény, ale mechanismus zajištění «mandatory TLS» není definován a v praxi je toto nastavení často zavedeno způsobem, který ani minimálně nechrání před skutečnými útoky, které jsou již předvídány v takových mechanismech jako DANE nebo MTA-STS.

Pokud regulátor vyžaduje realizaci «mandatory TLS» pro jednotlivé domény, doporučujeme zvážit MTA-STS nebo jeho částečný ekvivalent jako nejvhodnější mechanismus, který eliminuje potřebu provádět zabezpečená nastavení pro každou doménu zvlášť. Pokud máte potíže s realizací klientské části MTA-STS (zatímco protokol ještě nezískal širokou podporu, pravděpodobně budou), lze doporučit takový přístup:

1. Publikujte politiku MTA-STS a/nebo záznamy DANE (DANE má smysl přidávat, pouze pokud je pro vaši doménu již aktivován DNSSEC, a MTA-STS v každém případě), to ochrání provoz směrem k vám a zbaví vás nutnosti žádat jiné e-mailové služby o nastavení mandatory TLS pro vaši doménu, pokud e-mailová služba již podporuje MTA-STS a/nebo DANE.
2. Pro velké poštovní služby implementujte "analog" MTA-STS prostřednictvím samostatných nastavení transportu pro každou doménu, které zafixují MX používaný pro přeposílání pošty a budou vyžadovat povinnou kontrolu TLS certifikátu. Pokud domény již publikují politiku MTA-STS, pravděpodobně to půjde provést bez problémů. Samo o sobě zavedení povinného TLS pro doménu bez zafixování relé a kontroly certifikátu není na úrovni bezpečnosti efektivní a nic nepřidává k dosavadním mechanismům STARTTLS.

Zdroj: habr.com