Trumpai tariant, MTA-STS yra būdas toliau apsaugoti el. laiškus nuo perėmimo (t. y. „man-in-the-middle“ atakų, dar žinomų kaip MitM), kai jie perduodami tarp pašto serverių. Jis iš dalies išsprendžia senas el. pašto protokolų architektūrines problemas ir yra aprašytas palyginti neseniai priimtame standarte RFC 8461. Mail.ru yra pirmoji pagrindinė pašto paslauga „RuNet“, įdiegusi šį standartą. Ir tai išsamiau aprašyta po pjūviu.

Kokią problemą išsprendžia MTA-STS?

Istoriškai el. pašto protokolai (SMTP, POP3, IMAP) informaciją perduodavo aiškiu tekstu, todėl buvo galima ją perimti, pavyzdžiui, prisijungus prie ryšio kanalo.

Kaip atrodo vieno vartotojo laiško perdavimo kitam mechanizmas:

Istoriškai MitM ataka buvo įmanoma visose vietose, kur cirkuliuoja paštas.

RFC 8314 reikalauja naudoti TLS tarp pašto vartotojo programos (MUA) ir pašto serverio. Jei jūsų serveris ir jūsų naudojamos pašto programos atitinka RFC 8314, jūs (daugiausia) pašalinote „Man-in-the-Middle“ atakų tarp vartotojo ir pašto serverių galimybę.

Vadovaujantis visuotinai priimta praktika (standartizuota pagal RFC 8314), ataka šalia vartotojo pašalinama:

Mail.ru pašto serveriai atitiko RFC 8314 dar prieš priimant standartą; iš tikrųjų jis tiesiog fiksuoja jau priimtą praktiką ir mums nereikėjo nieko papildomai konfigūruoti. Tačiau jei jūsų pašto serveris vis tiek leidžia vartotojams naudoti nesaugius protokolus, būtinai įgyvendinkite šio standarto rekomendacijas, nes Labiausiai tikėtina, kad bent kai kurie jūsų vartotojai dirba su paštu be šifravimo, net jei jį palaikote.

Pašto klientas visada dirba su tuo pačiu tos pačios organizacijos pašto serveriu. Be to, galite priversti visus vartotojus prisijungti saugiai, o tada techniškai neįmanoma prisijungti nesaugiems vartotojams (būtent to reikalauja RFC 8314). Tai kartais sunku, bet įmanoma. Eismas tarp pašto serverių vis dar sudėtingesnis. Serveriai priklauso skirtingoms organizacijoms ir dažnai naudojami „nustatyti ir pamiršti“ režimu, todėl neįmanoma iš karto pereiti prie saugaus protokolo nepažeidžiant ryšio. SMTP jau seniai teikia STARTTLS plėtinį, leidžiantį serveriams, kurie palaiko šifravimą, pereiti prie TLS. Tačiau užpuolikas, galintis paveikti srautą, gali „iškirpti“ informaciją apie šios komandos palaikymą ir priversti serverius bendrauti naudodamas paprasto teksto protokolą (vadinamoji žemesnės versijos ataka). Dėl tos pačios priežasties STARTTLS dažniausiai netikrina sertifikato galiojimo (nepatikimas sertifikatas gali apsaugoti nuo pasyvių atakų, ir tai ne ką blogiau nei žinutės siuntimas aiškiu tekstu). Todėl STARTTLS apsaugo tik nuo pasyvaus pasiklausymo.

MTA-STS iš dalies pašalina laiškų perėmimo tarp pašto serverių problemą, kai užpuolikas turi galimybę aktyviai paveikti srautą. Jei gavėjo domenas skelbia MTA-STS politiką, o siuntėjo serveris palaiko MTA-STS, jis siųs el. laišką tik TLS ryšiu, tik į politikoje apibrėžtus serverius ir tik patikrinęs serverio sertifikatą.

Kodėl iš dalies? MTA-STS veikia tik tuo atveju, jei abi šalys pasirūpino, kad įgyvendintų šį standartą, o MTA-STS neapsaugo nuo scenarijų, kai užpuolikas gali gauti galiojantį domeno sertifikatą iš vienos iš viešųjų CA.

Kaip veikia MTA-STS

Gavėjas

Sukonfigūruoja STARTTLS palaikymą su galiojančiu sertifikatu pašto serveryje.
Skelbia MTA-STS politiką per HTTPS; paskelbimui naudojamas specialus mta-sts domenas ir specialus gerai žinomas kelias, pvz. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politikoje yra pašto serverių (mx), turinčių teisę gauti šio domeno laiškus, sąrašas.
Paskelbiamas specialus TXT įrašas _mta-sts DNS su politikos versija. Kai politika pasikeičia, šis įrašas turi būti atnaujintas (tai signalizuoja siuntėjui pakartotinai pateikti užklausą dėl politikos). Pavyzdžiui, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Siuntėjas

Siuntėjas prašo _mta-sts DNS įrašo ir, jei jis yra, pateikia politikos užklausą per HTTPS (tikrina sertifikatą). Gauta politika saugoma talpykloje (jei užpuolikas blokuoja prieigą prie jos arba sugadina DNS įrašą).

Siunčiant paštą patikrinama, ar:

serveris, į kurį pristatomas paštas, yra politikoje;
serveris priima paštą naudodamas TLS (STARTTLS) ir turi galiojantį sertifikatą.

MTA-STS privalumai

MTA-STS naudojamos technologijos, kurios jau yra įdiegtos daugumoje organizacijų (SMTP+STARTTLS, HTTPS, DNS). Norint įdiegti gavėjo pusėje, standartui nereikia jokio specialaus programinės įrangos palaikymo.

MTA-STS trūkumai

Būtina stebėti žiniatinklio ir pašto serverio sertifikato galiojimą, vardų atitikimą, savalaikį atnaujinimą. Dėl problemų, susijusių su sertifikatu, paštas negalės būti pristatytas.

Siuntėjo pusėje reikalingas MTA, palaikantis MTA-STS politiką; šiuo metu MTA-STS nepalaikoma iš karto MTA.

MTA-STS naudoja patikimų šakninių CA sąrašą.

MTA-STS neapsaugo nuo atakų, kurių metu užpuolikas naudoja galiojantį sertifikatą. Daugeliu atvejų MitM šalia serverio reiškia galimybę išduoti sertifikatą. Tokią ataką galima aptikti naudojant Certificate Transparency. Todėl apskritai MTA-STS sumažina, bet visiškai nepanaikina eismo perėmimo galimybę.

Paskutiniai du punktai daro MTA-STS mažiau saugų nei konkuruojantis DANE standartas SMTP (RFC 7672), tačiau techniškai patikimesnis, t.y. MTA-STS maža tikimybė, kad laiškas nebus pristatytas dėl techninių problemų, atsiradusių dėl standarto įgyvendinimo.

Varžybų standartas – DANE

DANE naudoja DNSSEC sertifikato informacijai skelbti ir nereikalauja pasitikėjimo išorinėmis sertifikatų institucijomis, o tai yra daug saugesnė. Tačiau DNSSEC naudojimas žymiai dažniau sukelia techninius gedimus, remiantis kelių naudojimo metų statistika (nors apskritai yra teigiamos DNSSEC ir jos techninės pagalbos patikimumo tendencijos). Norint įdiegti DANE SMTP gavėjo pusėje, DNSSEC buvimas DNS zonoje yra privalomas, o tinkamas NSEC/NSEC3 palaikymas yra būtinas DANE, dėl kurio kyla sisteminių DNSSEC problemų.

Jei DNSSEC nėra tinkamai sukonfigūruotas, tai gali sukelti laiškų pristatymo nesėkmes, jei siunčiančioji pusė palaiko DANE, net jei gaunančioji pusė apie tai nieko nežino. Todėl, nepaisant to, kad DANE yra senesnis ir saugesnis standartas ir jau palaikomas kai kuriose serverių programinės įrangos siuntėjo pusėje, iš tikrųjų jos skverbtis išlieka nereikšminga, daugelis organizacijų nepasirengusios jo įdiegti, nes reikia įdiegti DNSSEC, tai labai sulėtino DANE diegimą visus tuos metus, kai standartas egzistavo.

DANE ir MTA-STS neprieštarauja vienas kitam ir gali būti naudojami kartu.

Kas yra su MTA-STS palaikymu Mail.ru Mail?

Mail.ru jau kurį laiką skelbia MTA-STS politiką visoms pagrindinėms domenoms. Šiuo metu diegiame kliento standarto dalį. Rašymo metu politika yra taikoma neblokuojančiu režimu (jei pristatymas blokuojamas dėl politikos, laiškas bus pristatytas per „atsarginį“ serverį netaikant politikos), tada blokavimo režimas bus priverstinai taikomas nedidelei daliai. išeinančio SMTP srauto, palaipsniui 100 % srauto bus Palaikomas politikos vykdymas.

Kas dar palaiko standartą?

Iki šiol MTA-STS politika skelbia apie 0.05% aktyvių domenų, tačiau vis dėlto jau dabar apsaugo didelį laiškų srautą, nes Standartą palaiko pagrindiniai žaidėjai – Google, Comcast ir iš dalies Verizon (AOL, Yahoo). Daugelis kitų pašto tarnybų paskelbė, kad standarto palaikymas bus įdiegtas artimiausiu metu.

Kaip tai paveiks mane?

Nebent jūsų domene paskelbta MTA-STS politika. Jei paskelbsite politiką, jūsų pašto serverio naudotojų el. laiškai bus geriau apsaugoti nuo perėmimo.

Kaip įdiegti MTA-STS?

MTA-STS palaikymas gavėjo pusėje

Pakanka paskelbti politiką per HTTPS ir įrašus DNS, sukonfigūruoti galiojantį sertifikatą iš vienos iš patikimų CA (galima šifruoti) STARTTLS MTA (STARTTLS palaiko visi šiuolaikiniai MTA), jokio specialaus palaikymo iš Reikalingas MTA.

Žingsnis po žingsnio tai atrodo taip:

Naudojamame MTA sukonfigūruokite STARTTLS (postfix, exim, sendmail, Microsoft Exchange ir kt.).
Įsitikinkite, kad naudojate galiojantį sertifikatą (išdavė patikimas CA, nepasibaigęs, sertifikato tema sutampa su MX įrašu, kuriuo pristatomas jūsų domeno paštas).
Sukonfigūruokite TLS-RPT įrašą, per kurį bus pateiktos strategijos taikymo ataskaitos (paslaugoms, kurios palaiko TLS ataskaitų siuntimą). Įrašo pavyzdys (domenui example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Šis įrašas nurodo laiškų siuntėjams siųsti statistines ataskaitas apie TLS naudojimą SMTP [email protected].

Stebėkite ataskaitas keletą dienų, kad įsitikintumėte, jog nėra klaidų.
Paskelbkite MTA-STS politiką per HTTPS. Politika skelbiama kaip tekstinis failas su CRLF eilutės užbaigimo elementais pagal vietą.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Politikos pavyzdys:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Versijos lauke yra politikos versija (šiuo metu STSv1), Mode nustato politikos taikymo režimą, testavimas – testavimo režimas (politika netaikoma), enforce – „kovinis“ režimas. Pirmiausia paskelbkite politiką su režimu: testavimas, jei nėra problemų su politika testavimo režimu, po kurio laiko galite pereiti į režimą: enforce.

Mx yra nurodytas visų pašto serverių, galinčių priimti jūsų domeno paštą, sąrašas (kiekvienas serveris turi turėti sukonfigūruotą sertifikatą, atitinkantį mx nurodytą pavadinimą). Max_age nurodo strategijos saugojimo talpykloje laiką (kai įsiminta politika bus taikoma net jei užpuolikas blokuoja jos pristatymą arba sugadina DNS įrašus talpyklos metu, galite signalizuoti, kad reikia dar kartą pateikti politikos užklausą pakeisdami mta-sts DNS įrašas).
Paskelbkite TXT įrašą DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
ID lauke gali būti naudojamas savavališkas identifikatorius (pavyzdžiui, laiko žyma); pasikeitus strategijai, ji turėtų pasikeisti, o tai leidžia siuntėjams suprasti, kad jiems reikia iš naujo pateikti talpykloje saugomos politikos užklausą (jei identifikatorius skiriasi nuo talpykloje išsaugotas).

MTA-STS palaikymas siuntėjo pusėje

Kol kas su ja blogai, nes... šviežias standartas.

Exim – nėra integruoto palaikymo, yra trečiosios šalies scenarijus https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - nėra integruoto palaikymo, yra trečiosios šalies scenarijus, kuris išsamiai aprašytas Habré https://habr.com/en/post/424961/

Kaip pokalbis apie „privalomąjį TLS“

Pastaruoju metu reguliavimo institucijos atkreipia dėmesį į el. pašto saugumą (ir tai yra gerai). Pavyzdžiui, DMARC yra privalomas visoms JAV vyriausybinėms agentūroms ir vis labiau reikalingas finansų sektoriuje, o standarto skverbtis reguliuojamose srityse siekia 90 %. Dabar kai kurie reguliuotojai reikalauja įdiegti „privalomąjį TLS“ su atskirais domenais, tačiau „privalomo TLS“ užtikrinimo mechanizmas nėra apibrėžtas ir praktikoje šis nustatymas dažnai įgyvendinamas taip, kad net minimaliai neapsaugotų nuo realių atakų, kurios jau yra numatyta tokiuose mechanizmuose kaip DANE arba MTA-STS.

Jeigu reguliatorius reikalauja diegti „privalomąjį TLS“ su atskirais domenais, rekomenduojame tinkamiausiu mechanizmu laikyti MTA-STS arba jo dalinį analogą, tai pašalina poreikį kiekvienam domenui atskirai daryti saugius nustatymus. Jei kyla sunkumų diegiant MTA-STS kliento dalį (kol protokolas nebus plačiai palaikomas, jie greičiausiai tai padarys), galime rekomenduoti šį metodą:

Paskelbkite MTA-STS politiką ir (arba) DANE įrašus (DANE prasminga tik tuo atveju, jei DNSSEC jau įjungtas jūsų domene ir bet kuriuo atveju MTA-STS), tai apsaugos srautą jūsų kryptimi ir nereikės prašyti kitų el. pašto paslaugų. sukonfigūruoti privalomą TLS savo domenui, jei pašto paslauga jau palaiko MTA-STS ir (arba) DANE.
Didelėms el. pašto paslaugoms įdiekite MTA-STS „analogą“ naudodami atskirus transportavimo nustatymus kiekvienam domenui, kuris ištaisys pašto perdavimui naudojamą MX ir reikės privalomai patvirtinti jo TLS sertifikatą. Jei domenuose jau paskelbta MTA-STS politika, tai greičiausiai galima padaryti neskausmingai. Pats savaime įjungti privalomą TLS domenui nepataisius relės ir nepatikrinus jai skirto sertifikato yra neefektyvu saugumo požiūriu ir nieko neprideda prie esamų STARTTLS mechanizmų.

Šaltinis: www.habr.com

Mail.ru paštas pradeda taikyti MTA-STS politiką bandomuoju režimu