Röviden, az MTA-STS egy módja annak, hogy tovább védje az e-maileket az elfogástól (vagyis a köztes támadásoktól, más néven MitM-től), amikor a levelezőszerverek között továbbítják őket. Részben megoldja az e-mail protokollok örökölt architekturális problémáit, és a viszonylag friss RFC 8461 szabvány írja le. A Mail.ru a RuNet első olyan jelentős levelezési szolgáltatása, amely ezt a szabványt implementálja. És részletesebben le van írva a vágás alatt.
Milyen problémát old meg az MTA-STS?
A történelem során az e-mail protokollok (SMTP, POP3, IMAP) tiszta szövegben továbbították az információkat, ami lehetővé tette azok elfogását, például egy kommunikációs csatorna elérésekor.
Hogyan néz ki a levél egyik felhasználótól a másikhoz történő kézbesítésének mechanizmusa:
Történelmileg a MitM támadás minden olyan helyen lehetséges volt, ahol levél kering.
Az RFC 8314 megköveteli a TLS használatát a levelező felhasználói alkalmazás (MUA) és a levelezőszerver között. Ha a szervere és a használt levelezőalkalmazásai megfelelnek az RFC 8314 szabványnak, akkor (nagyrészt) 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.
Az általánosan elfogadott gyakorlatok követése (az RFC 8314 szabvány szerint) kiküszöböli a támadást a felhasználó közelében:
A Mail.ru levelezőszerverei már a szabvány elfogadása előtt is megfeleltek az RFC 8314 szabványnak, valójában egyszerűen rögzíti a már elfogadott gyakorlatokat, és nem kellett semmi további beállítást. De ha a levelezőszerver továbbra is engedélyezi a nem biztonságos protokollok használatát, feltétlenül hajtsa végre ennek a szabványnak az ajánlásait, mert Valószínűleg legalább néhány felhasználó titkosítás nélkül dolgozik a levelezéssel, még akkor is, ha Ön támogatja azt.
A levelezőkliens mindig ugyanannak a szervezetnek a levelezőszerverével működik. És rákényszerítheti az összes felhasználót a biztonságos csatlakozásra, majd technikailag lehetetlenné teheti a nem biztonságos felhasználók csatlakozását (az RFC 8314 pontosan ezt követeli meg). Ez néha nehéz, de kivitelezhető. A levelezőszerverek közötti forgalom még bonyolultabb. A szerverek különböző szervezetekhez tartoznak, és gyakran „beállít és felejtsd el” módban használják őket, ami lehetetlenné teszi a biztonságos protokollra való azonnali váltást a kapcsolat megszakítása nélkül. Az SMTP régóta biztosítja a STARTTLS kiterjesztést, amely lehetővé teszi a titkosítást támogató szerverek számára a TLS-re való átállást. De egy támadó, aki képes befolyásolni a forgalmat, „kivághatja” a parancs támogatásával kapcsolatos információkat, és arra kényszerítheti a szervereket, hogy egyszerű szöveges protokoll használatával kommunikáljanak (az úgynevezett downgrade támadás). Ugyanebből az okból kifolyólag a STARTTLS általában nem ellenőrzi a tanúsítvány érvényességét (a nem megbízható tanúsítvány védhet a passzív támadások ellen, és ez nem rosszabb, mint egy tiszta szöveges üzenet küldése). Ezért a STARTTLS csak a passzív lehallgatás ellen véd.
Az MTA-STS részben kiküszöböli a levelek elfogásának problémáját a levelezőszerverek között, amikor a támadó képes aktívan befolyásolni a forgalmat. Ha a címzett tartománya MTA-STS házirendet tesz közzé, és a küldő szervere támogatja az MTA-STS-t, akkor csak TLS-kapcsolaton keresztül küldi el az e-mailt, csak a házirendben meghatározott szerverekre, é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 gondoskodott ennek a szabványnak a megvalósításáról, és az MTA-STS nem véd az olyan forgatókönyvek ellen, amelyekben a támadó érvényes tartományi tanúsítványt szerezhet be valamelyik nyilvános CA-tól.
Hogyan működik az MTA-STS
befogadó
- Beállítja a STARTTLS támogatást egy érvényes tanúsítvánnyal a levelezőszerveren.
- Az MTA-STS házirendet HTTPS-en keresztül teszi közzé; egy speciális mta-sts tartományt és egy speciális jól ismert elérési utat használnak a közzétételhez, pl.
https://mta-sts.mail.ru/.well-known/mta-sts.txt. A házirend tartalmazza azon levelezőkiszolgálók (mx) listáját, amelyek jogosultak leveleket fogadni ebben a tartományban. - Egy speciális _mta-sts TXT rekordot tesz közzé a DNS-ben a házirend verziójával. Amikor a házirend megváltozik, ezt a bejegyzést frissíteni kell (ez jelzi a feladónak, hogy újra lekérdezze a házirendet). Például,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Feladó
A feladó lekéri a _mta-sts DNS rekordot, és ha elérhető, akkor HTTPS-en keresztül házirend-kérést intéz (ellenőrzi a tanúsítványt). Az eredményül kapott házirend gyorsítótárazásra kerül (ha egy támadó blokkolja a hozzáférést, vagy meghamisítja a DNS-rekordot).
Levélküldéskor ellenőrzi, hogy:
- a szerver, amelyre a leveleket kézbesítik, szerepel a házirendben;
- a szerver TLS (STARTTLS) használatával fogad leveleket, és rendelkezik érvényes tanúsítvánnyal.
Az MTA-STS előnyei
Az MTA-STS olyan technológiákat használ, amelyeket a legtöbb szervezet már bevezetett (SMTP+STARTTLS, HTTPS, DNS). A fogadó oldalon történő megvalósításhoz a szabványhoz nincs szükség speciális szoftvertámogatásra.
Az MTA-STS hátrányai
Figyelemmel kell kísérni a web- és levelezőszerver tanúsítvány érvényességét, a nevek egyezését, az időszerű megújítást. A tanúsítvánnyal kapcsolatos problémák azt eredményezik, hogy a levél nem kézbesíthető.
A küldő oldalon az MTA-STS szabályzatokat támogató MTA-ra van szükség; jelenleg az MTA-STS nem támogatott az MTA-ban.
Az MTA-STS a megbízható legfelső szintű hitelesítésszolgáltatók listáját használja.
Az MTA-STS nem nyújt védelmet azokkal a támadásokkal szemben, amelyekben a támadó érvényes tanúsítványt használ. A legtöbb esetben a szerver közelében lévő MitM magában foglalja a tanúsítvány kiadásának lehetőségét. Az ilyen támadás a Certificate Transparency segítségével észlelhető. Ezért az MTA-STS általában mérsékli, de nem szünteti meg teljesen a forgalomelfogás lehetőségét.
Az utolsó két pont az MTA-STS-t kevésbé biztonságossá teszi, mint a versengő DANE SMTP-szabvány (RFC 7672), de műszakilag megbízhatóbb, pl. az MTA-STS esetében kicsi a valószínűsége annak, hogy a levél kézbesítésére a szabvány megvalósításából adódó technikai problémák miatt nem kerül sor.
Versenyző standard - DANE
A DANE a DNSSEC-et használja a tanúsítványinformációk közzétételére, és nem igényel bizalmat a külső tanúsító hatóságokban, ami sokkal biztonságosabb. A DNSSEC használata azonban lényegesen gyakrabban vezet technikai hibákhoz, a több éves használat statisztikái alapján (bár általában pozitív tendencia figyelhető meg a DNSSEC és technikai támogatásának megbízhatóságában). A DANE SMTP-ben történő megvalósításához a címzett oldalon kötelező a DNSSEC jelenléte a DNS zónában, és az NSEC/NSEC3 megfelelő támogatása elengedhetetlen a DANE számára, amellyel rendszerszintű problémák vannak a DNSSEC-ben.
Ha a DNSSEC nincs megfelelően konfigurálva, az levélkézbesítési hibákhoz vezethet, ha a küldő oldal támogatja a DANE-t, még akkor is, ha a fogadó fél semmit sem tud róla. Ezért annak ellenére, hogy a DANE egy régebbi és biztonságosabb szabvány, és egyes szerverszoftverekben már támogatott a küldő oldalon, a penetrációja valójában továbbra is jelentéktelen, sok szervezet nem áll készen a bevezetésére a DNSSEC bevezetésének szükségessége miatt, ez jelentősen lelassította a DANE bevezetését mindaddig, amíg a szabvány fennállt.
A DANE és az MTA-STS nem ütközik egymással, és együtt használhatók.
Mi a helyzet az MTA-STS támogatással a Mail.ru Mailben?
A Mail.ru már jó ideje közzétesz egy MTA-STS szabályzatot minden nagyobb tartományra vonatkozóan. Jelenleg a szabvány kliens részét implementáljuk. A cikk írásakor a házirendek nem blokkoló módban vannak alkalmazva (ha a kézbesítést egy szabályzat blokkolja, a levél egy „tartalék” szerveren keresztül kézbesítik házirendek alkalmazása nélkül), akkor a blokkoló mód egy kis részre kényszerül. a kimenő SMTP forgalomból fokozatosan a forgalom 100%-a lesz A házirendek betartatása támogatott.
Ki támogatja még a szabványt?
Az MTA-STS házirendek eddig az aktív domainek körülbelül 0.05%-át teszik közzé, de ennek ellenére már nagy mennyiségű levélforgalom védelmét szolgálják, mert A szabványt a főbb szereplők – a Google, a Comcast és részben a Verizon (AOL, Yahoo) – támogatják. Sok más posta is bejelentette, hogy a közeljövőben bevezetik a szabvány támogatását.
Milyen hatással lesz ez rám?
Hacsak a domain nem tesz közzé MTA-STS szabályzatot. Ha közzéteszi a szabályzatot, a levelezőszerver felhasználóinak küldött e-mailjei jobban védettek lesznek a lehallgatás ellen.
Hogyan valósíthatom meg az MTA-STS-t?
MTA-STS támogatás a címzett oldalon
Elegendő a házirendet HTTPS-en keresztül közzétenni és a DNS-ben rekordokat, konfigurálni egy érvényes tanúsítványt valamelyik megbízható CA-tól (a titkosítás lehetséges) a STARTTLS-hez az MTA-ban (a STARTTLS-t minden modern MTA támogatja), nincs külön támogatás a MTA kötelező.
Lépésről lépésre így néz ki:
- Konfigurálja a STARTTLS-t a használt MTA-ban (postfix, exim, sendmail, Microsoft Exchange stb.).
- Győződjön meg arról, hogy érvényes tanúsítványt használ (megbízható CA által kibocsátott, nem lejárt, a tanúsítvány tárgya megegyezik azzal az MX rekorddal, amely a domain leveleit kézbesíti).
- Konfiguráljon egy TLS-RPT rekordot, amelyen keresztül a házirend-alkalmazási jelentések kézbesíthetők (a TLS-jelentések küldését támogató szolgáltatások által). Példabejegyzés (az example.com domainhez):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Ez a bejegyzés arra utasítja a levelezőket, hogy küldjenek statisztikai jelentéseket a TLS-használatról az SMTP-ben a címre
[email protected].Figyelje a jelentéseket néhány napig, hogy megbizonyosodjon arról, hogy nincsenek hibák.
- Tegye közzé az MTA-STS házirendet HTTPS-en keresztül. A házirendet szöveges fájlként teszik közzé hely szerint CRLF sorlezárókkal.
https://mta-sts.example.com/.well-known/mta-sts.txtPélda irányelv:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400A verzió mező tartalmazza a házirend verzióját (jelenleg
STSv1), A Mode beállítja a szabályzat alkalmazási módját, tesztelés — teszt mód (a házirend nincs alkalmazva), enforce — „harci” mód. Először tegye közzé a házirendet mode: teszteléssel, ha nincs probléma a házirenddel teszt módban, egy idő után át lehet váltani mód: enforce módba.Az mx-ben meg van adva az összes olyan levelezőszerver listája, amely képes fogadni a tartományhoz tartozó leveleket (minden kiszolgálón rendelkeznie kell egy, az mx-ben megadott névvel megegyező konfigurált tanúsítvánnyal). A Max_age megadja a házirend gyorsítótárazási idejét (ha a megjegyzett házirend akkor is alkalmazásra kerül, ha a támadó blokkolja annak kézbesítését vagy megsérti a DNS-rekordokat a gyorsítótárazási idő alatt, akkor jelezheti a házirend újbóli kérésének szükségességét az mta-sts DNS módosításával rekord).
- TXT rekord közzététele a DNS-ben:
_mta-sts.example.com. TXT “v=STS1; id=someid;”Az id mezőben tetszőleges azonosító (például időbélyeg) használható; ha a házirend megváltozik, annak változnia kell, így a feladók megérthetik, hogy újra kell kérniük a gyorsítótárazott házirendet (ha az azonosító eltér a gyorsítótárazott).
MTA-STS támogatás a küldő oldalon
Eddig rossz volt vele, mert... friss szabvány.
- Exim - nincs beépített támogatás, van egy harmadik féltől származó szkript
- Postfix - nincs beépített támogatás, van egy harmadik féltől származó szkript, amelyet részletesen leír a Habré
Utószóként a „kötelező TLS-ről”
Az utóbbi időben a szabályozók odafigyelnek az e-mailek biztonságára (és ez jó dolog). Például a DMARC kötelező az Egyesült Államok összes kormányzati ügynöksége számára, és egyre nagyobb igény van rá a pénzügyi szektorban, a szabvány elterjedése pedig eléri a 90%-ot a szabályozott területeken. Mostanra egyes szabályozók megkövetelik a „kötelező TLS” bevezetését az egyes tartományokhoz, de a „kötelező TLS” biztosításának mechanizmusa nincs meghatározva, és a gyakorlatban ezt a beállítást gyakran úgy hajtják végre, hogy még csak minimális védelmet se nyújtson a már megtörtént valós támadásokkal szemben. olyan mechanizmusokban, mint a DANE vagy az MTA-STS.
Ha a szabályozó megköveteli a „kötelező TLS” megvalósítását külön tartományokkal, javasoljuk, hogy az MTA-STS vagy annak részleges analógja legyen a legalkalmasabb mechanizmus, így nincs szükség minden tartományra vonatkozóan külön-külön biztonsági beállítások elvégzésére. Ha nehézségei vannak az MTA-STS kliens részének megvalósításával (amíg a protokoll nem kap széleskörű támogatást, valószínűleg meg is fogják), akkor ezt a megközelítést ajánljuk:
- Tegyen közzé egy MTA-STS-házirendet és/vagy DANE-rekordokat (a DANE-nek csak akkor van értelme, ha a DNSSEC már engedélyezve van a domainben, és az MTA-STS mindenképpen), ez megvédi az Ön felé irányuló forgalmat, és szükségtelenné teszi más levelezőszolgáltatások kérését. a kötelező TLS beállításához a tartományhoz, ha a levelezési szolgáltatás már támogatja az MTA-STS-t és/vagy a DANE-t.
- Nagy e-mail szolgáltatások esetén minden tartományhoz külön szállítási beállításokon keresztül valósítsa meg az MTA-STS „analógját”, ami javítja a levéltovábbításhoz használt MX-et, és megköveteli a TLS-tanúsítvány kötelező ellenőrzését. Ha a tartományok már közzétesznek MTA-STS-házirendet, ez valószínűleg fájdalommentesen megtehető. Önmagában a kötelező TLS engedélyezése egy tartományban a relé javítása és a hozzá tartozó tanúsítvány ellenőrzése nélkül biztonsági szempontból hatástalan, és nem ad hozzá semmit a meglévő STARTTLS-mechanizmusokhoz.
Forrás: will.com