Stručne povedané, MTA-STS je spôsob, ako ďalej chrániť e-maily pred zachytením (t. j. útokmi typu man-in-the-middle aka MitM) pri prenose medzi poštovými servermi. Čiastočne rieši staré architektonické problémy e-mailových protokolov a je opísaný v relatívne nedávnom štandarde RFC 8461. Mail.ru je prvou hlavnou poštovou službou na RuNet, ktorá implementuje tento štandard. A je to podrobnejšie popísané pod strihom.

Aký problém rieši MTA-STS?

Historicky e-mailové protokoly (SMTP, POP3, IMAP) prenášali informácie v čistom texte, čo umožňovalo ich zachytenie napríklad pri prístupe ku komunikačnému kanálu.

Ako vyzerá mechanizmus doručovania listu od jedného používateľa druhému:

Historicky bol útok MitM možný na všetkých miestach, kde koluje pošta.

RFC 8314 vyžaduje použitie TLS medzi poštovou užívateľskou aplikáciou (MUA) a poštovým serverom. Ak váš server a poštové aplikácie, ktoré používate, sú v súlade s RFC 8314, potom ste (do značnej miery) eliminovali možnosť útokov typu Man-in-the-Middle medzi používateľom a poštovými servermi.

Dodržiavanie všeobecne uznávaných postupov (štandardizovaných RFC 8314) eliminuje útok v blízkosti používateľa:

Poštové servery Mail.ru vyhovovali RFC 8314 ešte pred prijatím štandardu, v skutočnosti jednoducho zachytáva už prijaté postupy a nemuseli sme nič konfigurovať. Ak však váš poštový server stále umožňuje používateľom používať nezabezpečené protokoly, nezabudnite implementovať odporúčania tohto štandardu, pretože S najväčšou pravdepodobnosťou aspoň niektorí z vašich používateľov pracujú s poštou bez šifrovania, aj keď ho podporujete.

Poštový klient vždy pracuje s rovnakým poštovým serverom tej istej organizácie. A môžete prinútiť všetkých používateľov, aby sa pripojili bezpečným spôsobom, a potom technicky znemožniť pripojenie nezabezpečeným používateľom (presne to vyžaduje RFC 8314). To je niekedy ťažké, ale uskutočniteľné. Komunikácia medzi poštovými servermi je stále komplikovanejšia. Servery patria rôznym organizáciám a často sa používajú v režime „nastav a zabudni“, čo znemožňuje okamžité prepnutie na zabezpečený protokol bez prerušenia pripojenia. SMTP už dlho poskytuje rozšírenie STARTTLS, ktoré umožňuje serverom, ktoré podporujú šifrovanie, prejsť na TLS. Útočník, ktorý má schopnosť ovplyvňovať prevádzku, však môže „vystrihnúť“ informácie o podpore tohto príkazu a prinútiť servery komunikovať pomocou jednoduchého textového protokolu (tzv. downgrade útok). Z rovnakého dôvodu STARTTLS zvyčajne nekontroluje platnosť certifikátu (nedôveryhodný certifikát môže chrániť pred pasívnymi útokmi, a to nie je horšie ako zaslanie správy vo forme čistého textu). Preto STARTTLS chráni len pred pasívnym odpočúvaním.

MTA-STS čiastočne odstraňuje problém zachytávania listov medzi poštovými servermi, kedy má útočník možnosť aktívne ovplyvňovať prevádzku. Ak doména príjemcu publikuje politiku MTA-STS a server odosielateľa podporuje MTA-STS, odošle e-mail iba cez pripojenie TLS, iba na servery definované politikou a iba s overením certifikátu servera.

Prečo čiastočne? MTA-STS funguje iba vtedy, ak sa obe strany postarali o implementáciu tohto štandardu a MTA-STS nechráni pred scenármi, v ktorých je útočník schopný získať platný certifikát domény od jednej z verejných CA.

Ako funguje MTA-STS

príjemcu

Nakonfiguruje podporu STARTTLS s platným certifikátom na poštovom serveri.
Zverejňuje politiku MTA-STS cez HTTPS, na zverejnenie sa používa špeciálna doména mta-sts a špeciálna známa cesta, napr. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika obsahuje zoznam poštových serverov (mx), ktoré majú právo prijímať poštu pre túto doménu.
Zverejní špeciálny TXT záznam _mta-sts v DNS s verziou politiky. Keď sa politika zmení, táto položka sa musí aktualizovať (to signalizuje odosielateľovi, aby znova požiadal o politiku). Napríklad, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

odosielateľ

Odosielateľ si vyžiada DNS záznam _mta-sts a ak je dostupný, odošle požiadavku na politiku cez HTTPS (skontroluje certifikát). Výsledná politika sa uloží do vyrovnávacej pamäte (v prípade, že k nej útočník zablokuje prístup alebo sfalšuje DNS záznam).

Pri odosielaní pošty sa kontroluje, či:

server, na ktorý sa doručuje pošta, je v politike;
server prijíma poštu pomocou TLS (STARTTLS) a má platný certifikát.

Výhody MTA-STS

MTA-STS využíva technológie, ktoré sú už implementované vo väčšine organizácií (SMTP+STARTTLS, HTTPS, DNS). Na implementáciu na strane príjemcu nie je potrebná žiadna špeciálna softvérová podpora štandardu.

Nevýhody MTA-STS

Je potrebné sledovať platnosť certifikátu webového a mailového servera, zhodu mien a včasnú obnovu. Problémy s certifikátom budú mať za následok, že poštu nebude možné doručiť.

Na strane odosielateľa sa vyžaduje MTA s podporou politík MTA-STS, v súčasnosti nie je MTA-STS podporovaný hneď po vybalení v MTA.

MTA-STS používa zoznam dôveryhodných koreňových CA.

MTA-STS nechráni pred útokmi, pri ktorých útočník používa platný certifikát. Vo väčšine prípadov MitM v blízkosti servera znamená možnosť vydať certifikát. Takýto útok je možné odhaliť pomocou Certificate Transparency. Preto vo všeobecnosti MTA-STS zmierňuje, ale nie úplne odstraňuje, možnosť odpočúvania premávky.

Posledné dva body robia MTA-STS menej bezpečným ako konkurenčný štandard DANE pre SMTP (RFC 7672), ale technicky spoľahlivejším, t.j. pre MTA-STS je malá pravdepodobnosť, že list nebude doručený z dôvodu technických problémov spôsobených implementáciou normy.

Konkurenčný štandard - DANE

DANE používa DNSSEC na zverejňovanie informácií o certifikátoch a nevyžaduje dôveru v externé certifikačné autority, čo je oveľa bezpečnejšie. Ale používanie DNSSEC výrazne častejšie vedie k technickým zlyhaniam, na základe štatistík za niekoľko rokov používania (aj keď vo všeobecnosti existuje pozitívny trend v spoľahlivosti DNSSEC a jeho technickej podpore). Pre implementáciu DANE v SMTP na strane príjemcu je prítomnosť DNSSEC pre DNS zónu povinná a správna podpora NSEC/NSEC3 je nevyhnutná pre DANE, s ktorým sú v DNSSEC systémové problémy.

Ak DNSSEC nie je správne nakonfigurovaný, môže to mať za následok zlyhanie doručenia pošty, ak odosielajúca strana podporuje DANE, aj keď prijímajúca strana o tom nič nevie. Preto aj napriek tomu, že DANE je starší a bezpečnejší štandard a je už podporovaný v niektorých serverových softvéroch na strane odosielateľa, v skutočnosti je jeho penetrácia zanedbateľná, mnohé organizácie nie sú pripravené ho implementovať kvôli potrebe implementácie DNSSEC, to výrazne spomalilo implementáciu DANE po celé tie roky, čo norma existuje.

DANE a MTA-STS nie sú vo vzájomnom konflikte a môžu sa používať spoločne.

Čo je s podporou MTA-STS v Mail.ru Mail?

Mail.ru už nejaký čas publikuje politiku MTA-STS pre všetky hlavné domény. V súčasnosti implementujeme klientsku časť štandardu. V čase písania sú politiky aplikované v neblokujúcom režime (ak je doručovanie zablokované politikou, list bude doručený cez „náhradný“ server bez použitia politík), potom bude blokovací režim pre malú časť vynútený odchádzajúcej SMTP prevádzky, postupne pre 100% prevádzky bude podporované Presadzovanie politík.

Kto ešte podporuje štandard?

Politiky MTA-STS zatiaľ zverejňujú približne 0.05 % aktívnych domén, no napriek tomu už chránia veľký objem poštovej prevádzky, pretože Štandard podporujú hlavní hráči – Google, Comcast a čiastočne Verizon (AOL, Yahoo). Mnohé ďalšie poštové služby oznámili, že podpora štandardu bude implementovaná v blízkej budúcnosti.

Ako ma to ovplyvní?

Nie, pokiaľ vaša doména nezverejní politiku MTA-STS. Ak politiku zverejníte, e-maily pre používateľov vášho poštového servera budú lepšie chránené pred zachytením.

Ako implementujem MTA-STS?

Podpora MTA-STS na strane príjemcu

Stačí zverejniť politiku cez HTTPS a záznamy v DNS, nakonfigurovať platný certifikát od niektorej z dôveryhodných CA (Let's encrypt je možné) pre STARTTLS v MTA (STARTTLS je podporovaný vo všetkých moderných MTA), žiadna špeciálna podpora zo strany Vyžaduje sa MTA.

Krok za krokom to vyzerá takto:

Nakonfigurujte STARTTLS v MTA, ktorý používate (postfix, exim, sendmail, Microsoft Exchange atď.).
Uistite sa, že používate platný certifikát (vydaný dôveryhodnou CA, bez expirácie, predmet certifikátu sa zhoduje so záznamom MX, ktorý doručuje poštu pre vašu doménu).
Nakonfigurujte záznam TLS-RPT, prostredníctvom ktorého sa budú doručovať správy aplikácie politiky (službami, ktoré podporujú odosielanie správ TLS). Príklad záznamu (pre doménu example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Táto položka dáva pokyn odosielateľom pošty, aby odosielali štatistické správy o používaní TLS v SMTP na [email protected].

Monitorujte prehľady niekoľko dní, aby ste sa uistili, že v nich nie sú žiadne chyby.
Zverejnite politiku MTA-STS cez HTTPS. Politika je publikovaná ako textový súbor so zakončeniami riadkov CRLF podľa umiestnenia.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Príklad pravidiel:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Pole verzia obsahuje verziu politiky (aktuálne STSv1), Mode nastavuje režim aplikácie politiky, testovanie — testovací režim (neaplikuje sa politika), vynucovanie — „bojový“ režim. Najprv zverejnite politiku s režimom: testovanie, ak nie sú problémy s politikou v testovacom režime, po chvíli môžete prejsť do režimu: vynútiť.

V mx je zadaný zoznam všetkých poštových serverov, ktoré môžu prijímať poštu pre vašu doménu (každý server musí mať nakonfigurovaný certifikát, ktorý sa zhoduje s názvom zadaným v mx). Max_age určuje čas ukladania politiky do vyrovnávacej pamäte (akonáhle sa zapamätaná politika použije, aj keď útočník zablokuje jej doručenie alebo poškodí záznamy DNS počas času ukladania do vyrovnávacej pamäte, môžete signalizovať potrebu znova požiadať o politiku zmenou mta-sts DNS záznam).
Zverejnite záznam TXT v DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
V poli id možno použiť ľubovoľný identifikátor (napríklad časovú pečiatku); keď sa politika zmení, mala by sa zmeniť, čo umožňuje odosielateľom pochopiť, že musia znova požiadať o politiku uloženú vo vyrovnávacej pamäti (ak sa identifikátor líši od jeden z vyrovnávacej pamäte).

Podpora MTA-STS na strane odosielateľa

Zatiaľ je to s ňou zlé, lebo... čerstvý štandard.

Exim - žiadna vstavaná podpora, existuje skript tretej strany https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - nemá vstavanú podporu, existuje skript tretej strany, ktorý je podrobne popísaný na Habré https://habr.com/en/post/424961/

Ako doslov o „povinnom TLS“

V poslednej dobe regulačné orgány venujú pozornosť bezpečnosti e-mailov (a to je dobre). Napríklad DMARC je povinný pre všetky vládne agentúry v Spojených štátoch a je čoraz viac vyžadovaný vo finančnom sektore, pričom penetrácia štandardu dosahuje v regulovaných oblastiach 90 %. Teraz niektorí regulátori vyžadujú implementáciu „povinného TLS“ s jednotlivými doménami, ale mechanizmus zabezpečenia „povinného TLS“ nie je definovaný av praxi je toto nastavenie často implementované spôsobom, ktorý ani minimálne nechráni pred skutočnými útokmi, ktoré už sú stanovené v mechanizmoch ako DANE alebo MTA-STS.

Ak regulátor požaduje implementáciu „povinného TLS“ s oddelenými doménami, odporúčame zvážiť ako najvhodnejší mechanizmus MTA-STS alebo jeho čiastočný analóg, odpadá tak potreba bezpečného nastavenia pre každú doménu zvlášť. Ak máte problémy s implementáciou klientskej časti MTA-STS (kým protokol nezíska širokú podporu, s najväčšou pravdepodobnosťou budú), môžeme vám odporučiť tento prístup:

Zverejnite politiku MTA-STS a/alebo záznamy DANE (DANE má zmysel iba vtedy, ak je už pre vašu doménu povolený DNSSEC a v každom prípade MTA-STS), ochráni to prevádzku vo vašom smere a eliminuje potrebu pýtať sa iných poštových služieb na konfiguráciu povinného TLS pre vašu doménu, ak poštová služba už podporuje MTA-STS a/alebo DANE.
V prípade veľkých e-mailových služieb implementujte „analóg“ MTA-STS prostredníctvom samostatných nastavení prenosu pre každú doménu, čím sa opraví MX používaný na prenos pošty a bude sa vyžadovať povinné overenie certifikátu TLS. Ak domény už zverejňujú politiku MTA-STS, dá sa to pravdepodobne urobiť bezbolestne. Samotné povolenie povinného TLS pre doménu bez opravy relé a overenia certifikátu je z bezpečnostného hľadiska neúčinné a nepridáva nič k existujúcim STARTTLS mechanizmom.

Zdroj: hab.com

Mail.ru začína uplatňovať zásady MTA-STS v testovacom režime