Qısaca desək, MTA-STS e-poçtları poçt serverləri arasında ötürülən zaman ələ keçirməkdən (yəni, MitM kimi tanınan adam hücumlarından) qorumaq üçün bir yoldur. O, e-poçt protokollarının köhnə memarlıq problemlərini qismən həll edir və nisbətən yeni standart RFC 8461-də təsvir edilmişdir. Mail.ru RuNet-də bu standartı tətbiq edən ilk böyük poçt xidmətidir. Və bu, kəsik altında daha ətraflı təsvir edilmişdir.
MTA-STS hansı problemi həll edir?
Tarixən e-poçt protokolları (SMTP, POP3, IMAP) məlumatı aydın mətnlə ötürdü ki, bu da, məsələn, rabitə kanalına daxil olarkən onun qarşısını almağa imkan verdi.
Bir istifadəçidən digərinə məktubun çatdırılması mexanizmi nə kimi görünür:
Tarixən MitM hücumu poçtun yayıldığı bütün yerlərdə mümkün olub.
RFC 8314 poçt istifadəçi proqramı (MUA) və poçt serveri arasında TLS istifadəsini tələb edir. Əgər serveriniz və istifadə etdiyiniz poçt proqramları RFC 8314 ilə uyğundursa, siz (əsasən) istifadəçi və poçt serverləri arasında Man-in-the-Middle hücumları ehtimalını aradan qaldırmısınız.
Aşağıdakı ümumi qəbul edilmiş təcrübələr (RFC 8314 tərəfindən standartlaşdırılıb) istifadəçinin yaxınlığında hücumu aradan qaldırır:
Mail.ru poçt serverləri standart qəbul edilməmişdən əvvəl də RFC 8314-ə uyğun gəlirdi; əslində o, sadəcə olaraq artıq qəbul edilmiş təcrübələri ələ keçirir və əlavə heç nə konfiqurasiya etməli deyildik. Lakin, poçt serveriniz hələ də istifadəçilərə etibarsız protokollardan istifadə etməyə icazə verirsə, bu standartın tövsiyələrini yerinə yetirməyi unutmayın, çünki Çox güman ki, siz dəstək olsanız belə, istifadəçilərinizin heç olmasa bəziləri şifrələmədən poçtla işləyir.
Poçt müştərisi həmişə eyni təşkilatın eyni poçt serveri ilə işləyir. Və siz bütün istifadəçiləri təhlükəsiz şəkildə qoşulmağa məcbur edə bilərsiniz və sonra təhlükəsiz olmayan istifadəçilərin qoşulmasını texniki cəhətdən qeyri-mümkün edə bilərsiniz (RFC 8314 məhz bunu tələb edir). Bu bəzən çətin, lakin mümkündür. Poçt serverləri arasında trafik hələ də daha mürəkkəbdir. Serverlər müxtəlif təşkilatlara aiddir və tez-tez “quraşdır və unut” rejimində istifadə olunur ki, bu da əlaqəni kəsmədən bir anda təhlükəsiz protokola keçməyi qeyri-mümkün edir. SMTP çoxdan şifrələməni dəstəkləyən serverlərə TLS-ə keçməyə imkan verən STARTTLS genişlənməsini təmin etmişdir. Lakin trafikə təsir etmək qabiliyyətinə malik olan təcavüzkar bu əmrin dəstəyi ilə bağlı məlumatı “kəsdirə” və serverləri düz mətn protokolundan (sözdə endirmə hücumu) istifadə etməyə məcbur edə bilər. Eyni səbəbdən, STARTTLS adətən sertifikatın etibarlılığını yoxlamır (etibarsız sertifikat passiv hücumlardan qoruya bilər və bu, aydın mətndə mesaj göndərməkdən daha pis deyil). Buna görə də, STARTTLS yalnız passiv dinləmədən qoruyur.
MTA-STS, təcavüzkarın trafikə aktiv təsir göstərmək imkanına malik olduğu zaman poçt serverləri arasında məktubların tutulması problemini qismən aradan qaldırır. Əgər alıcının domeni MTA-STS siyasətini dərc edirsə və göndərənin serveri MTA-STS-ni dəstəkləyirsə, o, e-poçtu yalnız TLS bağlantısı vasitəsilə, yalnız siyasətlə müəyyən edilmiş serverlərə və yalnız server sertifikatının yoxlanılması ilə göndərəcək.
Niyə qismən? MTA-STS yalnız hər iki tərəf bu standartın həyata keçirilməsinə diqqət yetirdikdə işləyir və MTA-STS təcavüzkarın ictimai CA-lardan birindən etibarlı domen sertifikatı əldə edə biləcəyi ssenarilərdən qorunmur.
MTA-STS necə işləyir
Alıcı
- Poçt serverində etibarlı sertifikatla STARTTLS dəstəyini konfiqurasiya edir.
- MTA-STS siyasətini HTTPS vasitəsilə dərc edir; məsələn, dərc üçün xüsusi mta-sts domeni və xüsusi tanınmış yol istifadə olunur.
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Siyasət bu domen üçün poçt almaq hüququ olan poçt serverlərinin (mx) siyahısını ehtiva edir. - Siyasət versiyası ilə DNS-də _mta-sts xüsusi TXT qeydini dərc edir. Siyasət dəyişdikdə, bu giriş yenilənməlidir (bu, göndərənə siyasəti yenidən sorğulamaq üçün siqnal verir). Misal üçün,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Göndərən
Göndərən _mta-sts DNS qeydini tələb edir və əgər varsa, HTTPS vasitəsilə siyasət sorğusu göndərir (sertifikatı yoxlayır). Nəticədə siyasət keşlənir (təcavüzkar ona girişi bloklayır və ya DNS qeydini saxtalaşdırarsa).
Poçt göndərilərkən aşağıdakılar yoxlanılır:
- poçtun çatdırıldığı server siyasətdədir;
- server TLS (STARTTLS) istifadə edərək poçtu qəbul edir və etibarlı sertifikata malikdir.
MTA-STS-in üstünlükləri
MTA-STS artıq əksər təşkilatlarda tətbiq olunan texnologiyalardan istifadə edir (SMTP+STARTTLS, HTTPS, DNS). Alıcı tərəfdə həyata keçirmək üçün standart üçün xüsusi proqram təminatı tələb olunmur.
MTA-STS-in çatışmazlıqları
Veb və poçt serveri sertifikatının etibarlılığına, adların uyğunluğuna və vaxtında yenilənməsinə nəzarət etmək lazımdır. Sertifikatla bağlı problemlər poçtun çatdırıla bilməməsi ilə nəticələnəcək.
Göndərən tərəfdə MTA-STS siyasətlərini dəstəkləyən MTA tələb olunur; hazırda MTA-STS MTA-da qutudan kənar dəstəklənmir.
MTA-STS etibarlı kök CA-ların siyahısını istifadə edir.
MTA-STS təcavüzkarın etibarlı sertifikatdan istifadə etdiyi hücumlardan qorunmur. Əksər hallarda, server yaxınlığında MitM sertifikat vermək qabiliyyətini nəzərdə tutur. Belə bir hücum Sertifikat Şəffaflığı ilə aşkar edilə bilər. Buna görə də, ümumiyyətlə, MTA-STS nəqliyyatın qarşısının alınması ehtimalını azaldır, lakin tamamilə aradan qaldırmır.
Son iki məqam MTA-STS-ni SMTP üçün rəqabət aparan DANE standartından (RFC 7672) daha az təhlükəsiz edir, lakin texniki cəhətdən daha etibarlıdır, yəni. MTA-STS üçün standartın tətbiqi nəticəsində yaranan texniki problemlər səbəbindən məktubun çatdırılmaması ehtimalı azdır.
Rəqabət edən standart - DANE
DANE sertifikat məlumatlarını dərc etmək üçün DNSSEC-dən istifadə edir və xarici sertifikat orqanlarına etibar tələb etmir, bu da daha təhlükəsizdir. Lakin DNSSEC-in istifadəsi bir neçə illik istifadə statistikasına əsaslanaraq daha tez-tez texniki nasazlıqlara səbəb olur (baxmayaraq ki, DNSSEC-in etibarlılığında və onun texniki dəstəyində ümumiyyətlə müsbət tendensiya var). Alıcı tərəfdə SMTP-də DANE tətbiq etmək üçün DNS zonası üçün DNSSEC-in olması məcburidir və DNSSEC-də sistemli problemlərin mövcud olduğu DANE üçün NSEC/NSEC3 üçün düzgün dəstək vacibdir.
Əgər DNSSEC düzgün konfiqurasiya edilməyibsə, qəbul edən tərəf bu barədə heç nə bilməsə belə, göndərən tərəf DANE-i dəstəkləyirsə, bu, poçtun çatdırılmasında uğursuzluqlarla nəticələnə bilər. Buna görə də, DANE-nin daha köhnə və daha təhlükəsiz bir standart olmasına və göndərən tərəfdə bəzi server proqramlarında artıq dəstəklənməsinə baxmayaraq, əslində onun nüfuzu əhəmiyyətsiz olaraq qalır, bir çox təşkilat DNSSEC-in tətbiqi ehtiyacı səbəbindən onu həyata keçirməyə hazır deyil, bu, standartın mövcud olduğu bütün illərdə DANE-nin tətbiqini əhəmiyyətli dərəcədə yavaşlatdı.
DANE və MTA-STS bir-biri ilə ziddiyyət təşkil etmir və birlikdə istifadə edilə bilər.
Mail.ru Mail-də MTA-STS dəstəyi nədir?
Mail.ru uzun müddətdir ki, bütün əsas domenlər üçün MTA-STS siyasətini dərc edir. Hazırda standartın müştəri hissəsini həyata keçiririk. Yazı zamanı siyasətlər bloklanmayan rejimdə tətbiq edilir (əgər çatdırılma siyasət tərəfindən bloklanırsa, məktub siyasət tətbiq edilmədən “ehtiyat” server vasitəsilə çatdırılacaq), sonra bloklama rejimi kiçik bir hissə üçün məcbur ediləcək. gedən SMTP trafikinin, tədricən trafikin 100%-i üçün siyasətlərin tətbiqi dəstəklənir.
Standartı başqa kim dəstəkləyir?
İndiyə qədər MTA-STS siyasətləri aktiv domenlərin təxminən 0.05%-ni dərc edir, lakin buna baxmayaraq, onlar artıq böyük həcmdə poçt trafikini qoruyur, çünki Standart əsas oyunçular tərəfindən dəstəklənir - Google, Comcast və qismən Verizon (AOL, Yahoo). Bir çox digər poçt xidmətləri standarta dəstəyin yaxın gələcəkdə həyata keçiriləcəyini açıqladı.
Bu mənə necə təsir edəcək?
Domeniniz MTA-STS siyasətini dərc etmədikdə. Siyasəti dərc etsəniz, poçt serverinizin istifadəçiləri üçün e-poçtlar müdaxilədən daha yaxşı qorunacaq.
MTA-STS-i necə tətbiq edə bilərəm?
Alıcı tərəfdə MTA-STS dəstəyi
Siyasəti HTTPS və DNS-də qeydlər vasitəsilə dərc etmək, MTA-da STARTTLS üçün etibarlı CA-lardan birinin etibarlı sertifikatını konfiqurasiya etmək (Şifrələyək mümkündür) kifayətdir (STARTTLS bütün müasir MTA-larda dəstəklənir), heç bir xüsusi dəstək yoxdur. MTA tələb olunur.
Addım-addım bu kimi görünür:
- İstifadə etdiyiniz MTA-da STARTTLS-i konfiqurasiya edin (postfix, exim, sendmail, Microsoft Exchange və s.).
- Etibarlı sertifikatdan istifadə etdiyinizə əmin olun (etibarlı CA tərəfindən verilmiş, müddəti bitməmiş, sertifikatın mövzusu domeniniz üçün poçt göndərən MX qeydinə uyğundur).
- Siyasət tətbiqi hesabatlarının çatdırılacağı TLS-RPT qeydini konfiqurasiya edin (TLS hesabatlarının göndərilməsini dəstəkləyən xidmətlər tərəfindən). Giriş nümunəsi (example.com domeni üçün):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Bu giriş poçt göndərənlərə SMTP-də TLS istifadəsi ilə bağlı statistik hesabatları göndərmək üçün göstəriş verir.
[email protected].Heç bir səhv olmadığından əmin olmaq üçün hesabatları bir neçə gün izləyin.
- MTA-STS siyasətini HTTPS üzərindən dərc edin. Siyasət məkana görə CRLF xətt terminatorları ilə mətn faylı kimi dərc olunur.
https://mta-sts.example.com/.well-known/mta-sts.txtSiyasət nümunəsi:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Versiya sahəsində siyasətin versiyası var (hazırda
STSv1), Rejim siyasət tətbiqi rejimini təyin edir, sınaq — sınaq rejimi (siyasət tətbiq edilmir), tətbiq etmək — “döyüş” rejimi. Əvvəlcə rejimi rejimlə dərc edin: sınaq, əgər test rejimində siyasətlə bağlı problem yoxdursa, bir müddət sonra siz rejimə keçə bilərsiniz: tətbiq edin.mx-də domeniniz üçün poçtu qəbul edə bilən bütün poçt serverlərinin siyahısı müəyyən edilir (hər bir serverdə mx-də göstərilən ada uyğun konfiqurasiya edilmiş sertifikat olmalıdır). Max_age siyasətin keşləmə vaxtını müəyyən edir (xatırlanan siyasət hətta keşləmə zamanı onun çatdırılmasını bloklasa və ya DNS qeydlərini korlasa belə, yadda qalan siyasət tətbiq olunacaq, siz mta-sts DNS-ni dəyişdirərək siyasətin yenidən tələb edilməsinin zəruriliyini bildirə bilərsiniz. qeyd).
- DNS-də TXT qeydini dərc edin:
_mta-sts.example.com. TXT “v=STS1; id=someid;”İd sahəsində ixtiyari identifikator (məsələn, vaxt damğası) istifadə edilə bilər; siyasət dəyişdikdə, o, dəyişməlidir, bu, göndərənlərə keşlənmiş siyasətə yenidən müraciət etməli olduqlarını başa düşməyə imkan verir (əgər identifikator siyasətdən fərqlidirsə). keşlənmiş biri).
Göndərən tərəfdə MTA-STS dəstəyi
İndiyə qədər onunla pisdir, çünki... təzə standart.
- Exim - daxili dəstək yoxdur, üçüncü tərəf skripti var
- Postfix - daxili dəstək yoxdur, Habré-də ətraflı təsvir olunan üçüncü tərəf skripti var
"məcburi TLS" haqqında son söz kimi
Son vaxtlar tənzimləyicilər e-poçt təhlükəsizliyinə diqqət yetirirlər (və bu yaxşı bir şeydir). Məsələn, DMARC ABŞ-da bütün dövlət qurumları üçün məcburidir və tənzimlənən sahələrdə standartın nüfuzu 90%-ə çatmaqla maliyyə sektorunda getdikcə daha çox tələb olunur. İndi bəzi tənzimləyicilər fərdi domenlərlə “məcburi TLS”nin həyata keçirilməsini tələb edir, lakin “məcburi TLS”nin təmin edilməsi mexanizmi müəyyən edilməyib və praktikada bu parametr çox vaxt real hücumlardan minimum səviyyədə qorunmayan şəkildə həyata keçirilir. DANE və ya MTA-STS kimi mexanizmlərdə nəzərdə tutulmuşdur.
Əgər tənzimləyici ayrıca domenlərlə “məcburi TLS” tətbiqini tələb edirsə, MTA-STS və ya onun qismən analoqunu ən uyğun mexanizm kimi nəzərdən keçirməyi tövsiyə edirik, bu, hər bir domen üçün ayrıca təhlükəsiz parametrlər etmək ehtiyacını aradan qaldırır. MTA-STS-in müştəri hissəsini həyata keçirməkdə çətinlik çəkirsinizsə (protokol geniş dəstək alana qədər, çox güman ki, olacaq), biz bu yanaşmanı tövsiyə edə bilərik:
- MTA-STS siyasətini və/və ya DANE qeydlərini dərc edin (DANE yalnız domeniniz üçün artıq DNSSEC aktivləşdirilibsə və istənilən halda MTA-STS o zaman məna kəsb edir), bu sizin istiqamətinizdə olan trafiki qoruyacaq və digər e-poçt xidmətlərindən soruşmaq ehtiyacını aradan qaldıracaq. poçt xidməti artıq MTA-STS və/və ya DANE-ni dəstəkləyirsə, domeniniz üçün məcburi TLS-ni konfiqurasiya etmək.
- Böyük e-poçt xidmətləri üçün hər bir domen üçün ayrı-ayrı nəqliyyat parametrləri vasitəsilə MTA-STS-in “analoqunu” həyata keçirin ki, bu da poçtun ötürülməsi üçün istifadə olunan MX-i düzəldəcək və bunun üçün TLS sertifikatının məcburi yoxlanılmasını tələb edəcək. Domenlər artıq MTA-STS siyasətini dərc edirsə, bu, çox güman ki, ağrısız şəkildə edilə bilər. Öz-özünə releyi düzəltmədən və sertifikatı yoxlamadan domen üçün məcburi TLS-nin aktivləşdirilməsi təhlükəsizlik baxımından təsirsizdir və mövcud STARTTLS mexanizmlərinə heç nə əlavə etmir.
Mənbə: www.habr.com