Röviden, az MTA-STS egy módszer a levelek további védelmére a lehallgatás ellen (pl. Man-in-the-Middle támadások) a levelezőszerverek közötti átvitel során. Részben megoldja a levelezési protokollok örökölt architekturális problémáit, és a viszonylag új RFC 8461 szabványban van leírva. A Mail.ru a legnagyobb levelezőszolgáltatás az orosz piacon, amely ezt a szabványt megvalósította. Részletesebben a következő részben olvashat róla.

Milyen problémát old meg az MTA-STS?

Történelmileg a levelezési protokollok (SMTP, POP3, IMAP) nyílt formában továbbították az információt, ami lehetővé tette, hogy az lehallgatható legyen, például a kommunikációs csatorna elérésével.

Hogyan néz ki a levél kézbesítési mechanizmusa egyik felhasználótól a másikig:

Történelmileg a Man-in-the-Middle támadások lehetségesek voltak minden olyan helyen, ahol levelek áramlanak.

Az RFC 8314 szabvány kötelezővé teszi a TLS használatát a felhasználói levelezőprogram (MUA) és a levelezőszerver között. Ha a szervere és a használt levelezőalkalmazások megfelelnek az RFC 8314-nek, akkor (nagy mértékben) kiküszöbölte a Man-in-the-Middle támadások lehetőségét a felhasználó és a levelezőszerverek között.

A közösen elfogadott gyakorlatok (standardizált RFC 8314) kiküszöbölik a felhasználó közelében történő támadásokat:

A Mail.ru levelezőszerverek már az RFC 8314 szabvány elfogadása előtt is megfeleltek annak, valójában ez csak a már elfogadott gyakorlatokat rögzíti, és nekünk semmi további beállítást nem kellett végezni. De ha a levelezőszervere még mindig biztonságos protokollokon keresztül engedi a felhasználókat, feltétlenül valósítsa meg ennek a szabványnak az ajánlásait, mert valószínűleg a felhasználóinak egy része titkosítás nélküli levelezéssel dolgozik, még akkor is, ha Ön támogatja azt.

A levelezőkliensek mindig ugyanazzal a levelezőszerverrel dolgoznak, amely ugyanannak a szervezetnek a része. Kötelezheti az összes felhasználót, hogy biztonságosan csatlakozzanak, ezután pedig technikailag lehetetlenné teheti a nem biztonságos csatlakozást (ez pontosan az, amit az RFC 8314 megkövetel). Ez néha bonyolult, de megvalósítható. A levelezőszerverek közötti forgalom már sokkal bonyolultabb. A szerverek különböző szervezetekhez tartoznak, és gyakran „telepít és elfelejt” üzemmódban működnek, ami lehetetlenné teszi a biztonságos protokollra való azonnali áttérést a kapcsolat megszakítása nélkül. Az SMTP-ben már régóta létezik a STARTTLS kiterjesztés, amely lehetővé teszi az olyan szerverek számára, amelyek támogatják a titkosítást, hogy TLS-re váltanak. De a támadó, aki képes befolyásolni a forgalmat, „kivághatja” ennek a parancsnak a támogatásáról szóló információt, és rákényszerítheti a szervereket, hogy a szokásos szöveges protokollon kommunikáljanak (úgynevezett downgrade attack - a protokoll verziójának csökkentése). Ugyanezen okból a STARTTLS esetében általában nem ellenőrzik a tanúsítvány megfelelőségét (egy megbízhatatlan tanúsítvány védelmet nyújthat a passzív támadások ellen, és ez nem rosszabb, mint ha a levelet nyílt szövegben küldenénk). Ezért a STARTTLS csak a passzív lehallgatás ellen véd.

Az MTA-STS részben megszünteti a levelek lehallgatásának problémáját a levelezőszerverek között, amikor a támadónak lehetősége van aktívan befolyásolni a forgalmat. Ha a címzett domain MTA-STS politikát publikál, és az elküldő szerver támogatja az MTA-STS-t, akkor a levelet csak TLS-kapcsolaton keresztül, csak a politikában meghatározott szerverekre küldi, és csak a szerver tanúsítványának ellenőrzésével.

Miért részben? Az MTA-STS csak akkor működik, ha mindkét fél gondoskodik e szabvány bevezetéséről, és az MTA-STS nem véd meg az olyan scenárióktól, amikor a támadónak lehetősége van érvényes tanúsítványt szerezni a domainhez egy nyilvános CA-nál.

Hogyan működik az MTA-STS

Címzett

1. Beállítja a STARTTLS támogatását érvényes tanúsítvánnyal a levelezőszerveren. 
2. HTTPS-en keresztül publikálja az MTA-STS politikát, a publikálás egy speciális mta-sts domainen és egy különleges well-known úton történik, például https://mta-sts.mail.ru/.well-known/mta-sts.txt. A politika tartalmaz egy listát azokról a levelezőszerverekről (mx), amelyek jogosultak leveleket fogadni ehhez a domainhez.
3. Publikálja a speciális TXT-rekordot _mta-sts a DNS-ben a politika verziójával. A politika módosításakor ezt a rekordot frissíteni kell (ez jelet ad az elküldőnek arra, hogy újra kérje a politikát). Például, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Feladó

Az elküldő kéri a _mta-sts DNS-rekordot, amennyiben megtalálható, HTTPS-en keresztül kéri a politikát (ellenőrzi a tanúsítványt). A kapott politika gyorsítótárba kerül (arra az esetre, ha a támadó blokkolja a hozzáférést vagy hamisítja a DNS-rekordot).

E-mail küldésekor ellenőrzésre kerül, hogy:

• a kiszolgáló, amelyhez az e-mailt kézbesítik, szerepel a politikában;
• a kiszolgáló TLS (STARTTLS) használatával fogadja az e-mailt, és érvényes tanúsítvánnyal rendelkezik.

MTA-STS előnyei

Az MTA-STS olyan technológiákat használ, amelyeket a legtöbb szervezet már implementált (SMTP+STARTTLS, HTTPS, DNS). A fogadó oldalon nincs szükség külön programtámogatásra a szabványhoz.

MTA-STS hátrányai

Figyelemmel kell kísérni a web- és e-mailkiszolgáló tanúsítványának érvényességét, a nevek megfelelőségét és a határidős frissítéseket. Tanúsítvány problémák esetén lehetetlenné válik az e-mail kézbesítése.

Az elküldő oldalon olyan MTA szükséges, amely támogatja az MTA-STS politikákat, jelenleg "dobozból" az MTA-STS nem támogatott az MTA-ban.

Az MTA-STS megbízható gyökér CA-k listáját használja.

Az MTA-STS nem véd a támadások ellen, amelyeket a támadó érvényes tanúsítvánnyal hajt végre. A legtöbb esetben a MitM támadás a kiszolgáló közelében lehetővé teszi a tanúsítvány kibocsátását. Ilyen támadás észlelhető a Tanúsítvány Átláthatósága által. Ezért összességében az MTA-STS mérsékel, de teljesen nem szünteti meg a forgalom elfogásának lehetőségét.

Az utolsó két pont miatt az MTA-STS kevésbé védett, mint a versenyző DANE szabvány az SMTP számára (RFC 7672), de technikailag megbízhatóbb, azaz az MTA-STS esetében kicsi a valószínűsége annak, hogy az e-mail ne érkezzen meg a szabvány bevezetésével kapcsolatos technikai problémák miatt.

Versenyző szabvány — DANE

A DANE a DNSSEC-t használ a tanúsítványok információinak közzétételére, és nem igényel bizalmat külső tanúsító hatóságok iránt, ami sokkal biztonságosabb. Azonban a DNSSEC használata lényegesen gyakrabban vezet technikai hibákhoz, ha több éves használati statisztikára támaszkodunk (bár a DNSSEC megbízhatóságában és általában a technikai támogatásában pozitív tendencia figyelhető meg). A DANE megvalósításához az SMTP-nél a fogadó oldal DNS-zónájának DNSSEC-tel kell rendelkeznie, és a DANE-hez elengedhetetlen a helyes NSEC/NSEC3 támogatás, amellyel a DNSSEC-ben rendszerszintű problémák vannak.

Ha a DNSSEC hibásan van konfigurálva, az a levél kézbesítésének megtagadásához vezethet, ha a küldő fél támogatja a DANE-t, még akkor is, ha a fogadó fél nem tud róla. Ezért, noha a DANE egy régebbi és biztonságosabb szabvány, amelyet már támogat néhány küldői oldali szerverprogram, a gyakorlati elterjedése még mindig jelentéktelen, sok szervezet nem hajlandó bevezetni, mivel ez megköveteli a DNSSEC bevezetését, ami érdemben késleltette a DANE bevezetését azóta, hogy a szabvány létezik.

A DANE és az MTA-STS nem következnek egymásból, és együttesen is használhatók.

Milyen a támogatás MTA-STS-sel a Mail.ru-nál?

A Mail.ru már jó ideje közzéteszi az MTA-STS irányelvet minden fő domén esetében. Jelenleg a szabvány kliensoldali részének bevezetésén dolgozunk. A cikk írásának időpontjában az irányelvek nem blokkoló módban érvényesek (ha a kézbesítést az irányelv blokkolja, a levél a „tartalék” szerveren keresztül kerül kézbesítésre az irányelvek alkalmazása nélkül), majd egy kis részére a kimenő SMTP forgalomnak kötelező blokkoló módban lesz életben, fokozatosan támogatva az irányelvek alkalmazását a 100%-os forgalom számára.

Ki még támogatja a szabványt?

Jelenleg körülbelül 0,05% aktív domén publikálja az MTA-STS irányelveket, de ennek ellenére már jelentős mennyiségű levélforgalmat védenek, mivel a standardot nagy szereplők támogatják — Google, Comcast és részben a Verizon (AOL, Yahoo). Számos más levelezőszolgáltatás bejelentette, hogy a standard támogatása a közeljövőben megvalósításra kerül.

Milyen hatással lesz ez rám?

Semmiképpen, ha a domainje nem teszi közzé az MTA-STS politikát. Ha közzéteszi a politikát, akkor a levelek jobban védettek lesznek a felhasználók levelezőszervere számára a lehallgatás ellen.

Hogyan valósíthatom meg az MTA-STS-t?

MTA-STS támogatás a fogadó oldalon

Elég, ha közzéteszi a politikát HTTPS-en keresztül és a DNS bejegyzésekben, érvényes tanúsítványt kell konfigurálni egy megbízható CA-tól (az ingyenes Let's Encrypt is elegendő) a STARTTLS-hez az MTA-ban (a STARTTLS-t minden modern MTA támogatja), az MTA részéről külön támogatás nem szükséges.

Lépésről lépésre, így néz ki:

1. Konfigurálja a STARTTLS-t az Ön által használt MTA-ban (postfix, exim, sendmail, Microsoft Exchange stb.).
2. Győződjön meg róla, hogy érvényes tanúsítványt használ (megbízható CA által kiadott, nem lejárt, a tanúsítvány alanyának meg kell felelnie a MX-bekezdésnek, amelyen keresztül a postát kézbesítik az Ön domainjére).
3. Konfigurálja a TLS-RPT bejegyzést, amelyre a politikai alkalmazásokról szóló jelentések fognak érkezni (a jelentések küldését támogató szolgáltatók). Példa bejegyzés (képzeljük el, hogy a domain például example.com):

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

   Ez a bejegyzés utasítja a levelezők küldőit, hogy statisztikai jelentéseket küldjenek a TLS SMTP használatáról a következő címre tlsrpt@exmple.com.

   Kövesse a jelentéseket néhány napig, és győződjön meg róla, hogy nincsenek hibák.

4. Tegye közzé az MTA-STS politikát HTTPS-en. A politika szöveges fájlként kerül közzétételre sorvégződésekkel CRLF a megadott helyszínen.

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

   Példa politikára:

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

   A version mező a politika verzióját tartalmazza (jelenleg ez STSv1), a Mode adja meg a politika alkalmazási módját, a testing – teszt mód (a politika nem alkalmazható), enforce – „éles” mód. Először közzé kell tenni a politikát mode: testing módban, ha a politikával nincs probléma a teszt üzemmódban, egy idő múlva lehet váltani az enforce módra.

   A mx mezőben szerepel az összes levelező szerver listája, amelyek fogadhatják a leveleket az Ön domainjére (minden szervernek érvényes tanúsítvánnyal kell rendelkeznie, amely megfelel a megadott mx névnek). A max_age a politika gyorsítótárazási idejét határozza meg (egyszer már eltárolt politika akkor is alkalmazásra kerül, ha a támadó blokkolja annak visszaadását vagy megzavarja a DNS bejegyzéseket a gyorsítótárazási idő alatt, a politika újbóli kérésére a DNS mta-sts bejegyzés megváltoztatásával lehet jelezni).

5. Közzé kell tenni a DNS TXT-bejegyzést: 

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

   Az id mezőben tetszőleges azonosítót (például időbélyeget) használhatunk, amelynek a politika megváltoztatásakor módosulnia kell. Ez lehetővé teszi a küldők számára, hogy megértsék, hogy újra kell kérni a gyorsítótárba mentett politikát (ha az azonosító eltér a tárolttól).

MTA-STS támogatás a küldő oldalán

Jelenleg nem túl jól áll, mivel a szabvány új.

• Exim – nincs beépített támogatás, van egy harmadik fél által készített script https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix – nincs beépített támogatás, van egy részletesen ismertetett harmadik fél által készített script a Habr-on https://habr.com/en/post/424961/

A „mandatory TLS”-ről szóló zárszóként

Az utóbbi időben a szabályozók figyelmet fordítanak a levelezés biztonságára (ami jó). Például a DMARC kötelező minden állami intézmény számára az Egyesült Államokban, és egyre gyakrabban követelik a pénzügyi szektorban. A szabályozott területeken a standard elterjedtségének aránya eléri a 90%-ot. Jelenleg néhány szabályozó megköveteli a „mandatory TLS” bevezetését bizonyos domainekkel, de ezen mechanizmusok biztosításának módját nem határozzák meg, és a gyakorlatban ezt a beállítást gyakran olyan módon valósítják meg, amely még minimálisan sem véd a valós támadások ellen, amelyeket már olyan mechanizmusok keretein belül terveztek, mint a DANE vagy az MTA-STS.

Ha a szabályozó megköveteli a „mandatory TLS” bevezetését bizonyos domainekkel, javasoljuk, hogy fontolja meg az MTA-STS-t vagy a részleges analógját, mint a legmegfelelőbb mechanizmust, mivel ez megszünteti a biztonságos beállítások egyes domainekre való külön-külön történő alkalmazásának szükségességét. Ha nehézségei vannak az MTA-STS kliensoldali részének megvalósításával (mivel a protokoll még nem kapott széleskörű támogatást, valószínűleg ezek előfordulni fognak), javasolhatunk egy ilyen megközelítést:

1. Tegye közzé az MTA-STS politikát és/vagy a DANE bejegyzéseket (a DANE-nek értelme van hozzáadni csak akkor, ha az Ön domainje már DNSSEC-t használ, míg az MTA-STS mindenképpen), ez védi az Ön irányába irányuló forgalmat, és megszünteti a szükségességet, hogy más levelező szolgáltatásoktól kérje a mandatory TLS beállítását az Ön domainjéhez, ha a levelező szolgáltatás már támogatja az MTA-STS-t és/vagy a DANE-t.
2. Nagyobb levelezőszolgáltatók esetében valósítsák meg a MTA-STS „analógját” minden egyes domainhez külön beállítások révén, amelyek rögzítik az MX-et, amelyet a levelek átkonfigurálásához használnak, és kötelezően megkövetelik a TLS-tanúsítvány ellenőrzését. Ha a domainek már közzétették az MTA-STS irányelvet, ez valószínűleg fájdalommentesen megtehető. Magának a kötelező TLS-nek a bekapcsolása egy domain esetében relé fixálása és tanúsítványának ellenőrzése nélkül nem hatékony a biztonság szempontjából, és nem ad semmit a meglévő STARTTLS mechanizmusokhoz.

Forrás: habr.com