Stručně řečeno, MTA-STS je způsob, jak dále chránit e-maily před zachycením (tj. útoky typu man-in-the-middle aka MitM) při přenosu mezi poštovními servery. Částečně řeší staré architektonické problémy e-mailových protokolů a je popsán v relativně nedávném standardu RFC 8461. Mail.ru je první velká poštovní služba na RuNet, která tento standard implementuje. A blíže je to popsáno pod střihem.

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

Historicky e-mailové protokoly (SMTP, POP3, IMAP) přenášely informace v čistém textu, což umožňovalo jejich zachycení například při přístupu ke komunikačnímu kanálu.

Jak vypadá mechanismus doručování dopisu od jednoho uživatele druhému:

Historicky byl útok MitM možný na všech místech, kde koluje pošta.

RFC 8314 vyžaduje použití TLS mezi poštovní uživatelskou aplikací (MUA) a poštovním serverem. Pokud váš server a poštovní aplikace, které používáte, jsou v souladu s RFC 8314, pak jste (z velké části) eliminovali možnost útoků typu Man-in-the-Middle mezi uživatelem a poštovními servery.

Dodržování obecně uznávaných postupů (standardizovaných RFC 8314) eliminuje útok v blízkosti uživatele:

Mailové servery Mail.ru vyhovovaly RFC 8314 ještě před přijetím standardu, ve skutečnosti to prostě zachycuje již přijaté postupy a nemuseli jsme nic konfigurovat. Pokud však váš poštovní server stále umožňuje uživatelům používat nezabezpečené protokoly, nezapomeňte implementovat doporučení tohoto standardu, protože S největší pravděpodobností alespoň někteří z vašich uživatelů pracují s poštou bez šifrování, i když jej podporujete.

Poštovní klient vždy pracuje se stejným poštovním serverem stejné organizace. A můžete přinutit všechny uživatele, aby se připojili bezpečným způsobem, a pak technicky znemožnit připojení nezabezpečeným uživatelům (přesně to vyžaduje RFC 8314). To je někdy těžké, ale proveditelné. Komunikace mezi poštovními servery je stále komplikovanější. Servery patří různým organizacím a často se používají v režimu „nastav a zapomeň“, což znemožňuje okamžité přepnutí na zabezpečený protokol bez přerušení připojení. SMTP již dlouho poskytuje rozšíření STARTTLS, které umožňuje serverům, které podporují šifrování, přejít na TLS. Útočník, který má možnost ovlivňovat provoz, však může informace o podpoře tohoto příkazu „vystřihnout“ a donutit servery ke komunikaci pomocí prostého textového protokolu (tzv. downgrade útok). Ze stejného důvodu STARTTLS obvykle nekontroluje platnost certifikátu (nedůvěryhodný certifikát může chránit před pasivními útoky, a to není o nic horší, než poslat zprávu v čistém textu). STARTTLS proto chrání pouze před pasivním odposlechem.

MTA-STS částečně odstraňuje problém zachycování dopisů mezi poštovními servery, kdy má útočník možnost aktivně ovlivňovat provoz. Pokud doména příjemce publikuje politiku MTA-STS a server odesílatele podporuje MTA-STS, odešle e-mail pouze přes připojení TLS, pouze na servery definované politikou a pouze s ověřením certifikátu serveru.

Proč částečně? MTA-STS funguje pouze v případě, že se obě strany postaraly o implementaci tohoto standardu, a MTA-STS nechrání před scénáři, ve kterých je útočník schopen získat platný doménový certifikát od jedné z veřejných CA.

Jak funguje MTA-STS

příjemce

Nakonfiguruje podporu STARTTLS s platným certifikátem na poštovním serveru.
Zveřejňuje politiku MTA-STS přes HTTPS, k publikaci se používá speciální doména mta-sts a speciální známá cesta, např. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Zásada obsahuje seznam poštovních serverů (mx), které mají právo přijímat poštu pro tuto doménu.
Publikuje speciální TXT záznam _mta-sts v DNS s verzí zásady. Když se zásada změní, musí být tato položka aktualizována (to signalizuje odesílateli, aby znovu požádal o zásadu). Například, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Odesílatel

Odesílatel si vyžádá DNS záznam _mta-sts, a pokud je k dispozici, provede požadavek na politiku prostřednictvím HTTPS (kontrola certifikátu). Výsledná politika se uloží do mezipaměti (pro případ, že by k ní útočník zablokoval přístup nebo podvrhl DNS záznam).

Při odesílání pošty se kontroluje, že:

server, na který je pošta doručována, je v zásadě;
server přijímá poštu pomocí 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 žádná speciální softwarová podpora standardu.

Nevýhody MTA-STS

Je nutné hlídat platnost certifikátu webového a mailového serveru, shodu jmen a včasnou obnovu. Problémy s certifikátem způsobí, že pošta nebude moci být doručena.

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

MTA-STS používá seznam důvěryhodných kořenových certifikačních autorit.

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 v blízkosti serveru znamená možnost vydat certifikát. Takový útok lze detekovat pomocí Certificate Transparency. Obecně tedy MTA-STS zmírňuje, ale zcela nevylučuje, možnost rušení provozu.

Poslední dva body činí MTA-STS méně bezpečným než konkurenční standard DANE pro SMTP (RFC 7672), ale technicky spolehlivějším, tzn. u MTA-STS je malá pravděpodobnost, že dopis nebude doručen z důvodu technických problémů způsobených implementací normy.

Konkurenční standard - DANE

DANE používá DNSSEC k publikování informací o certifikátech a nevyžaduje důvěru v externí certifikační autority, což je mnohem bezpečnější. Používání DNSSEC však výrazně častěji vede k technickým poruchám, a to na základě statistik za několik let používání (ačkoli obecně existuje pozitivní trend ve spolehlivosti DNSSEC a jeho technické podpoře). Pro implementaci DANE v SMTP na straně příjemce je přítomnost DNSSEC pro DNS zónu povinná a správná podpora NSEC/NSEC3 je nezbytná pro DANE, se kterým jsou v DNSSEC systémové problémy.

Pokud není DNSSEC správně nakonfigurováno, může to mít za následek selhání doručování pošty, pokud odesílající strana podporuje DANE, i když o tom přijímající strana nic neví. Přestože je DANE starší a bezpečnější standard a je již podporován v některém serverovém softwaru na straně odesílatele, ve skutečnosti zůstává jeho penetrace nevýznamná, mnoho organizací není připraveno jej implementovat z důvodu potřeby implementace DNSSEC, to výrazně zpomalilo implementaci DANE po celá ta léta, co norma existuje.

DANE a MTA-STS nejsou ve vzájemném rozporu a lze je používat společně.

Co je s podporou MTA-STS v Mail.ru Mail?

Mail.ru již nějakou dobu publikuje politiku MTA-STS pro všechny hlavní domény. V současné době implementujeme klientskou část standardu. V době psaní tohoto článku jsou zásady aplikovány v neblokujícím režimu (pokud je doručení blokováno zásadou, bude dopis doručen prostřednictvím „náhradního“ serveru bez použití zásad), poté bude režim blokování pro malou část vynucen. odchozího provozu SMTP, postupně u 100 % provozu bude podporováno Vynucování zásad.

Kdo další standard podporuje?

Politiky MTA-STS zatím publikují přibližně 0.05 % aktivních domén, ale přesto již chrání velký objem poštovního provozu, protože Standard podporují hlavní hráči – Google, Comcast a částečně Verizon (AOL, Yahoo). Mnoho dalších poštovních služeb oznámilo, že podpora standardu bude implementována v blízké budoucnosti.

Jak mě to ovlivní?

Ne, pokud vaše doména nepublikuje zásady MTA-STS. Pokud zásady zveřejníte, e-maily pro uživatele vašeho poštovního serveru budou lépe chráněny před zachycením.

Jak implementuji MTA-STS?

Podpora MTA-STS na straně příjemce

Stačí publikovat politiku přes HTTPS a záznamy v DNS, nakonfigurovat platný certifikát od některé z důvěryhodných CA (Let's encrypt je možné) pro STARTTLS v MTA (STARTTLS je podporován ve všech moderních MTA), žádná speciální podpora ze strany Je vyžadován MTA.

Krok za krokem to vypadá takto:

Nakonfigurujte STARTTLS v MTA, který používáte (postfix, exim, sendmail, Microsoft Exchange atd.).
Ujistěte se, že používáte platný certifikát (vydaný důvěryhodnou CA, nevypršela platnost, předmět certifikátu odpovídá záznamu MX, který doručuje poštu pro vaši doménu).
Nakonfigurujte záznam TLS-RPT, jehož prostřednictvím budou doručovány sestavy aplikací zásad (službami, které podporují odesílání sestav TLS). Příklad záznamu (pro doménu example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Tento záznam dává pokyn odesílatelům pošty, aby posílali statistické zprávy o využití TLS v SMTP na [email protected].

Sledujte přehledy několik dní, abyste se ujistili, že v nich nejsou žádné chyby.
Publikovat zásady MTA-STS přes HTTPS. Zásada je publikována jako textový soubor se zakončením řádků CRLF podle umístění.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Příklad zásad:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Pole verze obsahuje verzi zásady (aktuálně STSv1), Mode nastavuje režim aplikace politiky, testování — testovací režim (nepoužívá se politika), vynucování — „bojový“ režim. Nejprve publikujte politiku s režimem: testování, pokud nejsou problémy s politikou v testovacím režimu, po chvíli můžete přejít do režimu: vynutit.

V mx je uveden seznam všech poštovních serverů, které mohou přijímat poštu pro vaši doménu (každý server musí mít nakonfigurovaný certifikát, který odpovídá názvu uvedenému v mx). Max_age určuje čas ukládání zásady do mezipaměti (jakmile bude zapamatovaná zásada použita, i když útočník zablokuje její doručení nebo poškodí záznamy DNS během doby ukládání do mezipaměti, můžete signalizovat potřebu znovu požádat o zásadu změnou mta-sts DNS záznam).
Publikování TXT záznamu v DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
V poli id lze použít libovolný identifikátor (například časové razítko); když se změní politika, měla by se změnit, to umožňuje odesílatelům pochopit, že musí znovu požádat o politiku uloženou v mezipaměti (pokud se identifikátor liší od jeden v mezipaměti).

Podpora MTA-STS na straně odesílatele

Zatím je to s ní špatné, protože... čerstvý standard.

Exim - žádná vestavěná podpora, existuje skript třetí strany https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - není vestavěná podpora, existuje skript třetí strany, který je podrobně popsán na Habré https://habr.com/en/post/424961/

Jako doslov o „povinném TLS“

V poslední době regulační orgány věnují pozornost zabezpečení e-mailů (a to je dobře). Například DMARC je povinný pro všechny vládní agentury ve Spojených státech a je stále více vyžadován ve finančním sektoru, přičemž penetrace standardu dosahuje v regulovaných oblastech 90 %. Nyní někteří regulátoři požadují implementaci „povinného TLS“ s jednotlivými doménami, ale mechanismus zajištění „povinného TLS“ není definován a v praxi je toto nastavení často implementováno způsobem, který ani minimálně nechrání před skutečnými útoky, které již jsou stanoveny v mechanismech jako DANE nebo MTA-STS.

Pokud regulátor požaduje implementaci „povinného TLS“ s oddělenými doménami, doporučujeme zvážit jako nejvhodnější mechanismus MTA-STS nebo jeho částečnou obdobu, odpadá tak nutnost bezpečného nastavení pro každou doménu zvlášť. Pokud máte potíže s implementací klientské části MTA-STS (dokud protokol nezíská širokou podporu, s největší pravděpodobností budou), můžeme doporučit tento přístup:

Zveřejněte politiku MTA-STS a/nebo záznamy DANE (DANE má smysl pouze v případě, že je pro vaši doménu již povoleno DNSSEC, a MTA-STS v každém případě), ochráníte tak provoz ve vašem směru a eliminujete potřebu ptát se jiných e-mailových služeb pro konfiguraci povinného TLS pro vaši doménu, pokud poštovní služba již podporuje MTA-STS a/nebo DANE.
U velkých e-mailových služeb implementujte „analog“ MTA-STS prostřednictvím samostatných nastavení přenosu pro každou doménu, což opraví MX používaný pro předávání pošty a bude vyžadovat povinné ověření certifikátu TLS. Pokud domény již publikují zásady MTA-STS, lze to pravděpodobně provést bezbolestně. Samo o sobě je povolení povinného TLS pro doménu bez opravy relay a ověření certifikátu pro ni z bezpečnostního hlediska neúčinné a nepřidává nic ke stávajícím mechanismům STARTTLS.

Zdroj: www.habr.com

Mail.ru začíná uplatňovat zásady MTA-STS v testovacím režimu