Mail.ru pochtasi MTA-STS siyosatlarini test rejimida qo'llashni boshlaydi

Mail.ru pochtasi MTA-STS siyosatlarini test rejimida qo'llashni boshlaydi

Muxtasar qilib aytganda, MTA-STS pochta serverlari o'rtasida uzatilganda elektron pochta xabarlarini to'xtatib turishdan (ya'ni, o'rtadagi odam hujumlari aka MitM) himoya qilishning bir usuli hisoblanadi. U elektron pochta protokollarining eski me'moriy muammolarini qisman hal qiladi va nisbatan yaqinda RFC 8461 standartida tasvirlangan. Mail.ru RuNetda ushbu standartni joriy qilgan birinchi yirik pochta xizmatidir. Va u kesim ostida batafsilroq tasvirlangan.

MTA-STS qanday muammoni hal qiladi?

Tarixiy jihatdan elektron pochta protokollari (SMTP, POP3, IMAP) ma'lumotni aniq matnda uzatdi, bu esa, masalan, aloqa kanaliga kirishda uni ushlab turish imkonini berdi.

Bir foydalanuvchidan boshqasiga xatni etkazish mexanizmi qanday ko'rinishga ega:

Mail.ru pochtasi MTA-STS siyosatlarini test rejimida qo'llashni boshlaydi

Tarixiy jihatdan, MitM hujumi pochta jo'natmalari tarqaladigan barcha joylarda mumkin edi.

RFC 8314 pochta foydalanuvchi ilovasi (MUA) va pochta serveri o'rtasida TLS dan foydalanishni talab qiladi. Agar sizning serveringiz va siz foydalanadigan pochta ilovalari RFC 8314 bilan mos bo'lsa, siz (asosan) foydalanuvchi va pochta serverlari o'rtasida Man-in-the-Middle hujumlari ehtimolini yo'q qilgansiz.

Quyidagi umumiy qabul qilingan amaliyotlar (RFC 8314 tomonidan standartlashtirilgan) foydalanuvchi yaqinidagi hujumni bartaraf qiladi:

Mail.ru pochtasi MTA-STS siyosatlarini test rejimida qo'llashni boshlaydi

Mail.ru pochta serverlari RFC 8314 standarti qabul qilinishidan oldin ham mos edi; aslida u allaqachon qabul qilingan amaliyotlarni qamrab oladi va biz qo'shimcha hech narsa sozlashimiz shart emas edi. Ammo, agar sizning pochta serveringiz hali ham foydalanuvchilarga xavfli protokollardan foydalanishga ruxsat bersa, ushbu standart tavsiyalarini bajaring, chunki Ehtimol, sizning foydalanuvchilaringizning hech bo'lmaganda ba'zilari, hatto siz uni qo'llab-quvvatlasangiz ham, shifrlashsiz pochta bilan ishlaydi.

Pochta mijozi har doim bir xil tashkilotning bir xil pochta serveri bilan ishlaydi. Va siz barcha foydalanuvchilarni xavfsiz tarzda ulanishga majbur qilishingiz mumkin va keyin xavfsiz bo'lmagan foydalanuvchilarning ulanishini texnik jihatdan imkonsiz qilishingiz mumkin (bu RFC 8314 talab qiladigan narsa). Bu ba'zan qiyin, lekin amalga oshirish mumkin. Pochta serverlari orasidagi trafik hali ham murakkabroq. Serverlar turli tashkilotlarga tegishli va ko'pincha "o'rnatish va unutish" rejimida qo'llaniladi, bu esa ulanishni buzmasdan bir vaqtning o'zida xavfsiz protokolga o'tishni imkonsiz qiladi. SMTP uzoq vaqtdan beri shifrlashni qo'llab-quvvatlaydigan serverlarga TLS ga o'tish imkonini beruvchi STARTTLS kengaytmasini taqdim etgan. Ammo trafikka ta'sir o'tkazish qobiliyatiga ega bo'lgan tajovuzkor ushbu buyruqni qo'llab-quvvatlash haqidagi ma'lumotni "kesib qo'yishi" mumkin va serverlarni oddiy matn protokoli (pastga tushirish hujumi deb ataladi) yordamida muloqot qilishga majbur qilishi mumkin. Xuddi shu sababga ko'ra, STARTTLS odatda sertifikatning haqiqiyligini tekshirmaydi (ishonchsiz sertifikat passiv hujumlardan himoya qilishi mumkin va bu aniq matnda xabar yuborishdan ko'ra yomonroq emas). Shuning uchun STARTTLS faqat passiv tinglashdan himoya qiladi.

MTA-STS, agar tajovuzkor trafikka faol ta'sir ko'rsatish qobiliyatiga ega bo'lsa, pochta serverlari orasidagi xatlarni ushlab qolish muammosini qisman yo'q qiladi. Qabul qiluvchining domeni MTA-STS siyosatini nashr etsa va jo'natuvchining serveri MTA-STSni qo'llab-quvvatlasa, u elektron pochta xabarini faqat TLS ulanishi orqali, faqat siyosatda belgilangan serverlarga va faqat server sertifikatini tekshirish bilan yuboradi.

Nima uchun qisman? MTA-STS faqat ikkala tomon ushbu standartni amalga oshirishga g'amxo'rlik qilgan taqdirdagina ishlaydi va MTA-STS tajovuzkor ommaviy CAlardan birida tegishli domen sertifikatini olishi mumkin bo'lgan stsenariylardan himoya qilmaydi.

MTA-STS qanday ishlaydi

Qabul qiluvchi

  1. Pochta serverida joriy sertifikat bilan STARTTLS qo‘llab-quvvatlashini sozlaydi. 
  2. MTA-STS siyosatini HTTPS orqali e'lon qiladi; masalan, nashr qilish uchun maxsus mta-sts domeni va maxsus taniqli yo'l ishlatiladi. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Siyosat ushbu domen uchun xat olish huquqiga ega bo'lgan pochta serverlari (mx) ro'yxatini o'z ichiga oladi.
  3. Siyosat versiyasi bilan DNS-da _mta-sts maxsus TXT yozuvini nashr etadi. Siyosat o'zgarganda, ushbu yozuv yangilanishi kerak (bu jo'natuvchiga siyosatni qayta so'rash uchun signal beradi). Masalan, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Yuboruvchi

Yuboruvchi _mta-sts DNS yozuvini so'raydi va agar u mavjud bo'lsa, HTTPS orqali siyosat so'rovini yuboradi (sertifikatni tekshirish). Olingan siyosat keshlanadi (agar tajovuzkor unga kirishni bloklasa yoki DNS yozuvini soxta qilsa).

Pochta jo'natishda quyidagilar tekshiriladi:

  • pochta yuboriladigan server siyosatda mavjud;
  • server TLS (STARTTLS) yordamida pochtani qabul qiladi va tegishli sertifikatga ega.

MTA-STS ning afzalliklari

MTA-STS ko'pchilik tashkilotlarda joriy qilingan texnologiyalardan foydalanadi (SMTP+STARTTLS, HTTPS, DNS). Qabul qiluvchi tomonda amalga oshirish uchun standart uchun maxsus dasturiy ta'minot talab qilinmaydi.

MTA-STS ning kamchiliklari

Veb va pochta serveri sertifikatining amal qilish muddatini, nomlarning mos kelishini va o'z vaqtida yangilanishini kuzatish kerak. Sertifikat bilan bog'liq muammolar pochta jo'natilishiga olib keladi.

Yuboruvchi tomondan MTA-STS siyosatlarini qo'llab-quvvatlaydigan MTA talab qilinadi; hozirda MTA-STS MTA qutisidan tashqarida qo'llab-quvvatlanmaydi.

MTA-STS ishonchli ildiz CA ro'yxatidan foydalanadi.

MTA-STS tajovuzkor haqiqiy sertifikatdan foydalanadigan hujumlardan himoya qilmaydi. Ko'pgina hollarda, server yaqinidagi MitM sertifikat berish imkoniyatini nazarda tutadi. Bunday hujumni Sertifikat shaffofligi yordamida aniqlash mumkin. Shuning uchun, umuman olganda, MTA-STS yo'l harakati to'xtatilishi ehtimolini yumshatadi, lekin butunlay yo'q qilmaydi.

Oxirgi ikki nuqta MTA-STSni SMTP uchun raqobatdosh DANE standartiga (RFC 7672) qaraganda kamroq xavfsiz qiladi, lekin texnik jihatdan ishonchliroq, ya'ni. MTA-STS uchun standartni amalga oshirish natijasida yuzaga kelgan texnik muammolar tufayli xatning yetkazilmasligi ehtimoli past.

Raqobatchi standart - DANE

DANE sertifikat ma'lumotlarini nashr qilish uchun DNSSEC dan foydalanadi va tashqi sertifikat organlariga ishonchni talab qilmaydi, bu esa ancha xavfsizroqdir. Ammo DNSSEC-dan foydalanish ko'pincha bir necha yillik foydalanish statistikasiga asoslangan texnik nosozliklarga olib keladi (garchi DNSSEC ishonchliligi va uni texnik qo'llab-quvvatlashda umuman ijobiy tendentsiya mavjud bo'lsa ham). Qabul qiluvchi tomonda SMTP-da DANE-ni amalga oshirish uchun DNS zonasi uchun DNSSEC-ning mavjudligi majburiydir va DNSSEC-da tizimli muammolar mavjud bo'lgan DANE uchun NSEC/NSEC3-ni to'g'ri qo'llab-quvvatlash juda muhimdir.

Agar DNSSEC to'g'ri sozlanmagan bo'lsa, agar jo'natuvchi tomon DANE-ni qo'llab-quvvatlasa, xatni qabul qiluvchi tomon bu haqda hech narsa bilmasa ham, bu pochta jo'natmalarida xatolikka olib kelishi mumkin. Shu sababli, DANE eskiroq va xavfsizroq standart bo'lib, jo'natuvchi tomonidagi ba'zi server dasturlarida allaqachon qo'llab-quvvatlanganiga qaramay, aslida uning kirib borishi ahamiyatsiz bo'lib qolmoqda, ko'plab tashkilotlar DNSSEC-ni joriy qilish zarurati tufayli uni amalga oshirishga tayyor emas, bu standart mavjud bo'lgan yillar davomida DANE-ning joriy etilishini sezilarli darajada sekinlashtirdi.

DANE va MTA-STS bir-biriga zid kelmaydi va birgalikda ishlatilishi mumkin.

Mail.ru Mail-da MTA-STS-ni qo'llab-quvvatlash nima?

Mail.ru ancha vaqtdan beri barcha asosiy domenlar uchun MTA-STS siyosatini nashr etib kelmoqda. Biz hozirda standartning mijoz qismini joriy qilmoqdamiz. Yozish vaqtida siyosatlar bloklanmaydigan rejimda qo'llaniladi (agar yetkazib berish siyosat tomonidan bloklangan bo'lsa, xat siyosatni qo'llamasdan "zaxira" server orqali yetkaziladi), keyin blokirovka rejimi kichik qismga majburlanadi. chiquvchi SMTP trafigi, asta-sekin 100% trafik uchun u bo'ladi Siyosatlarning bajarilishi qo'llab-quvvatlanadi.

Standartni yana kim qo'llab-quvvatlaydi?

Hozirgacha MTA-STS siyosati faol domenlarning taxminan 0.05 foizini nashr etadi, ammo shunga qaramay, ular allaqachon katta hajmdagi pochta trafigini himoya qiladi, chunki Standart yirik o'yinchilar tomonidan qo'llab-quvvatlanadi - Google, Comcast va qisman Verizon (AOL, Yahoo). Ko'pgina boshqa pochta xizmatlari standartni qo'llab-quvvatlash yaqin kelajakda amalga oshirilishini e'lon qildi.

Bu menga qanday ta'sir qiladi?

Domeningiz MTA-STS siyosatini nashr qilmasa. Agar siz siyosatni e'lon qilsangiz, pochta serveringiz foydalanuvchilari uchun elektron pochta xabarlari ushlashdan yaxshiroq himoyalangan bo'ladi.

MTA-STSni qanday amalga oshiraman?

Qabul qiluvchi tomonda MTA-STS qo'llab-quvvatlashi

Siyosatni HTTPS va DNS-dagi yozuvlar orqali nashr etish, MTA-dagi STARTTLS uchun ishonchli CA-lardan birining (Shifrlash mumkin) haqiqiy sertifikatini sozlash kifoya (STARTTLS barcha zamonaviy MTA-larda qo'llab-quvvatlanadi), maxsus yordam yo'q. MTA talab qilinadi.

Bosqichma-bosqich, u quyidagicha ko'rinadi:

  1. Siz foydalanayotgan MTA da STARTTLS ni sozlang (postfix, exim, sendmail, Microsoft Exchange va boshqalar).
  2. Yaroqli sertifikatdan foydalanayotganingizga ishonch hosil qiling (ishonchli CA tomonidan berilgan, muddati o‘tmagan, sertifikat mavzusi domeningiz uchun pochta jo‘natuvchi MX yozuviga mos keladi).
  3. Siyosat ilovasi hisobotlari yetkaziladigan TLS-RPT yozuvini sozlang (TLS hisobotlarini yuborishni qoʻllab-quvvatlaydigan xizmatlar tomonidan). Misol kiritish (example.com domeni uchun):
    smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

    Ushbu yozuv pochta joʻnatuvchilariga SMTP-da TLS-dan foydalanish boʻyicha statistik hisobotlarni yuborishni buyuradi. [email protected].

    Xatolar yo'qligiga ishonch hosil qilish uchun hisobotlarni bir necha kun davomida kuzatib boring.

  4. MTA-STS siyosatini HTTPS orqali nashr qiling. Siyosat joylashuv bo'yicha CRLF qator terminatorlari bilan matn fayli sifatida nashr etiladi.
    https://mta-sts.example.com/.well-known/mta-sts.txt
    

    Misol siyosati:

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

    Versiya maydonida siyosat versiyasi mavjud (hozirda STSv1), Mode siyosatni qo'llash rejimini, test - sinov rejimini (siyosat qo'llanilmaydi), majburlash - "jangovar" rejimini o'rnatadi. Avval siyosatni rejim bilan e'lon qiling: test, agar test rejimida siyosat bilan bog'liq muammolar bo'lmasa, bir muncha vaqt o'tgach siz rejimga o'tishingiz mumkin: majburlash.

    mx-da domeningiz uchun pochtani qabul qila oladigan barcha pochta serverlari ro'yxati ko'rsatilgan (har bir server mx-da ko'rsatilgan nomga mos keladigan sertifikatga ega bo'lishi kerak). Max_age siyosatning keshlash vaqtini belgilaydi (xatto tajovuzkor uni yetkazib berishni bloklasa yoki keshlash vaqtida DNS yozuvlarini buzsa ham eslab qolingan siyosat qo‘llaniladi, siz mta-sts DNS-ni o‘zgartirish orqali siyosatni qayta so‘rash zarurligini bildirishingiz mumkin. rekord).

  5. DNS-da TXT yozuvini nashr qilish: 
    _mta-sts.example.com. TXT “v=STS1; id=someid;”
    

    Identifikator maydonida ixtiyoriy identifikatordan (masalan, vaqt tamg'asi) foydalanish mumkin; siyosat o'zgarganda, u o'zgarishi kerak, bu jo'natuvchilarga keshlangan siyosatni qayta so'rashlari kerakligini tushunish imkonini beradi (agar identifikator belgilanganidan boshqacha bo'lsa). keshlangan).

Yuboruvchi tomonida MTA-STS qo'llab-quvvatlashi

Hozircha u bilan yomon, chunki ... yangi standart.

"Majburiy TLS" haqida so'z sifatida

So'nggi paytlarda regulyatorlar elektron pochta xavfsizligiga e'tibor berishdi (va bu yaxshi narsa). Misol uchun, DMARC Qo'shma Shtatlardagi barcha davlat idoralari uchun majburiy bo'lib, moliyaviy sektorda tobora ko'proq talab qilinmoqda, tartibga solinadigan hududlarda standartning kirib borishi 90% ga etadi. Endi ba'zi regulyatorlar alohida domenlar bilan "majburiy TLS" ni amalga oshirishni talab qilmoqdalar, ammo "majburiy TLS" ni ta'minlash mexanizmi aniqlanmagan va amalda bu sozlama ko'pincha allaqachon mavjud bo'lgan haqiqiy hujumlardan minimal darajada himoya qilmaydigan tarzda amalga oshiriladi. DANE yoki MTA-STS kabi mexanizmlarda nazarda tutilgan.

Agar regulyator alohida domenlar bilan "majburiy TLS" ni amalga oshirishni talab qilsa, MTA-STS yoki uning qisman analogini eng mos mexanizm sifatida ko'rib chiqishni tavsiya qilamiz, bu har bir domen uchun alohida xavfsiz sozlamalarni o'rnatish zaruratini yo'q qiladi. Agar siz MTA-STSning mijoz qismini amalga oshirishda qiyinchiliklarga duch kelsangiz (protokol keng miqyosda qo'llab-quvvatlanmaguncha, ular katta ehtimol bilan), biz ushbu yondashuvni tavsiya qilishimiz mumkin:

  1. MTA-STS siyosatini va/yoki DANE yozuvlarini nashr eting (DANE faqat domeningiz uchun DNSSEC allaqachon yoqilgan bo'lsa va MTA-STS har qanday holatda ham mantiqiy bo'ladi), bu sizning yo'nalishingizdagi trafikni himoya qiladi va boshqa pochta xizmatlaridan so'rash zaruratini yo'q qiladi. Agar pochta xizmati MTA-STS va/yoki DANE-ni qo'llab-quvvatlasa, domeningiz uchun majburiy TLSni sozlash.
  2. Katta elektron pochta xizmatlari uchun har bir domen uchun alohida transport sozlamalari orqali MTA-STS "analogini" amalga oshiring, bu pochta o'tkazish uchun ishlatiladigan MXni tuzatadi va buning uchun TLS sertifikatini majburiy tekshirishni talab qiladi. Agar domenlar MTA-STS siyosatini allaqachon e'lon qilgan bo'lsa, buni og'riqsiz bajarish mumkin. O'z-o'zidan domen uchun majburiy TLSni o'rni o'rnatmasdan va uning sertifikatini tekshirmasdan yoqish xavfsizlik nuqtai nazaridan samarasiz va mavjud STARTTLS mexanizmlariga hech narsa qo'shmaydi.

Manba: www.habr.com

a Izoh qo'shish