Товчхондоо MTA-STS нь цахим шуудангийн серверүүдийн хооронд дамжих үед тасалдалаас (жишээ нь, хүн-д-дунд халдлага гэх мэт MitM гэх мэт) имэйлийг хамгаалах арга юм. Энэ нь цахим шуудангийн протоколуудын архитектурын асуудлуудыг хэсэгчлэн шийдэж, харьцангуй сүүлийн үеийн стандарт RFC 8461-д тайлбарласан болно. Mail.ru бол RuNet-д энэ стандартыг хэрэгжүүлсэн анхны томоохон шуудангийн үйлчилгээ юм. Мөн энэ нь захын дор илүү дэлгэрэнгүй тайлбарласан байна.

MTA-STS ямар асуудлыг шийддэг вэ?

Түүхийн хувьд имэйлийн протоколууд (SMTP, POP3, IMAP) мэдээллийг тодорхой текстээр дамжуулдаг байсан бөгөөд энэ нь жишээлбэл, харилцаа холбооны сувагт нэвтрэх үед түүнийг таслан зогсоох боломжийг олгосон.

Нэг хэрэглэгчээс нөгөө хэрэглэгчдэд захидал хүргэх механизм нь юу вэ?

Түүхэнд MitM халдлага нь шуудан эргэлддэг бүх газарт боломжтой байсан.

RFC 8314 нь шуудангийн хэрэглэгчийн програм (MUA) болон шуудангийн серверийн хооронд TLS ашиглахыг шаарддаг. Хэрэв таны сервер болон таны ашигладаг мэйл програмууд RFC 8314-тэй нийцэж байгаа бол та хэрэглэгч болон шуудангийн серверүүдийн хооронд Man-in-the-Middle халдлага хийх боломжийг (ихэвчлэн) устгасан гэсэн үг.

Дараах нийтээр хүлээн зөвшөөрөгдсөн практик (RFC 8314 стандартын дагуу) нь хэрэглэгчийн ойролцоох халдлагыг арилгана:

Mail.ru мэйл серверүүд нь стандартыг батлахаас өмнө RFC 8314 стандартыг дагаж мөрддөг байсан; үнэн хэрэгтээ энэ нь аль хэдийн хүлээн зөвшөөрөгдсөн туршлагыг агуулдаг бөгөөд бид нэмэлт зүйл тохируулах шаардлагагүй байв. Гэсэн хэдий ч, хэрэв таны имэйл сервер хэрэглэгчдэд аюултай протокол ашиглахыг зөвшөөрдөг бол энэ стандартын зөвлөмжийг хэрэгжүүлэхээ мартуузай. Хамгийн багадаа таны зарим хэрэглэгчид та үүнийг дэмждэг байсан ч шифрлэлтгүйгээр шуудангаар ажилладаг байх магадлалтай.

Мэйл клиент нь нэг байгууллагын ижил имэйл сервертэй үргэлж ажилладаг. Мөн та бүх хэрэглэгчдийг аюулгүйгээр холбохыг албадаж, дараа нь аюулгүй бус хэрэглэгчдэд холбогдох техникийн боломжгүй болгож болно (энэ нь RFC 8314-д яг хэрэгтэй зүйл). Энэ нь заримдаа хэцүү, гэхдээ хийх боломжтой. Мэйл сервер хоорондын урсгал илүү төвөгтэй хэвээр байна. Серверүүд нь өөр өөр байгууллагад харьяалагддаг бөгөөд ихэвчлэн "тогтоож, мартах" горимд ашиглагддаг бөгөөд энэ нь холболтыг таслахгүйгээр аюулгүй протокол руу нэг дор шилжих боломжгүй болгодог. SMTP нь шифрлэлтийг дэмждэг серверүүдэд TLS руу шилжих боломжийг олгодог STARTTLS өргөтгөлөөр хангасаар ирсэн. Гэхдээ замын хөдөлгөөнд нөлөөлөх чадвартай халдагчид энэ командын дэмжлэгийн талаарх мэдээллийг "тасалж", серверүүдийг энгийн текстийн протокол ашиглан харилцахыг албадах боломжтой (дэвшилтийг бууруулах халдлага гэж нэрлэдэг). Үүнтэй ижил шалтгаанаар STARTTLS ихэвчлэн гэрчилгээний хүчинтэй эсэхийг шалгадаггүй (найдваргүй гэрчилгээ нь идэвхгүй халдлагаас хамгаалж чаддаг бөгөөд энэ нь тодорхой текстээр мессеж илгээхээс муу зүйл биш юм). Тиймээс STARTTLS нь зөвхөн идэвхгүй чагналтаас хамгаалдаг.

MTA-STS нь халдагчид урсгалд идэвхтэй нөлөөлөх чадвартай бол шуудангийн серверүүдийн хооронд захидал саатуулах асуудлыг хэсэгчлэн арилгадаг. Хэрэв хүлээн авагчийн домэйн MTA-STS бодлогыг нийтэлж, илгээгчийн сервер MTA-STS-ийг дэмждэг бол энэ нь зөвхөн TLS холболтоор имэйлийг зөвхөн бодлогод тодорхойлсон серверүүд рүү илгээх бөгөөд зөвхөн серверийн гэрчилгээг баталгаажуулсан тохиолдолд илгээх болно.

Яагаад хэсэгчлэн? MTA-STS нь зөвхөн хоёр тал энэ стандартыг хэрэгжүүлэхэд анхаарал хандуулсан тохиолдолд л ажилладаг бөгөөд MTA-STS нь халдагч олон нийтийн CA-ын аль нэгээс хүчинтэй домэйн гэрчилгээ авах боломжтой хувилбараас хамгаалахгүй.

MTA-STS хэрхэн ажилладаг

Хүлээн авагч

1. Мэйл сервер дээрх хүчинтэй сертификат бүхий STARTTLS дэмжлэгийг тохируулна. 
2. MTA-STS бодлогыг HTTPS-ээр дамжуулан нийтэлдэг; жишээлбэл, нийтлэхэд тусгай mta-sts домэйн болон сайн мэддэг тусгай замыг ашигладаг. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Уг бодлого нь энэ домэйны имэйл хүлээн авах эрхтэй мэйл серверүүдийн (mx) жагсаалтыг агуулна.
3. Тусгай TXT бичлэгийг _mta-sts DNS-д бодлогын хувилбараар нийтэлдэг. Бодлого өөрчлөгдөх үед энэ оруулгыг шинэчлэх шаардлагатай (энэ нь илгээгчээс бодлогыг дахин асуух дохио болно). Жишээлбэл, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Илгээгч

Илгээгч нь _mta-sts DNS бичлэгийг хүсэх бөгөөд хэрэв боломжтой бол HTTPS (сертификатыг шалгаж)-аар дамжуулан бодлогын хүсэлт гаргадаг. Үүссэн удирдамжийг кэшээр хадгална (халдагчид түүнд хандах хандалтыг блоклох эсвэл DNS бичлэгийг хуурамчаар үйлдэх тохиолдолд).

Захиа илгээхдээ дараахь зүйлийг шалгана.

• шуудан хүргэх сервер бодлогод байгаа;
• сервер нь TLS (STARTTLS) ашиглан захидал хүлээн авдаг бөгөөд хүчинтэй гэрчилгээтэй.

MTA-STS-ийн давуу тал

MTA-STS нь ихэнх байгууллагад аль хэдийн хэрэгжсэн технологиудыг ашигладаг (SMTP+STARTTLS, HTTPS, DNS). Хүлээн авагч талд хэрэгжүүлэхийн тулд стандартын тусгай програм хангамжийн дэмжлэг шаардлагагүй.

MTA-STS-ийн сул талууд

Вэб болон шуудангийн серверийн гэрчилгээний хүчинтэй байдал, нэрсийн захидал харилцаа, цаг тухайд нь шинэчлэхэд хяналт тавих шаардлагатай. Сертификаттай холбоотой асуудал гарвал шуудан хүргэх боломжгүй болно.

Илгээгчийн талаас MTA-STS бодлогуудыг дэмждэг MTA шаардлагатай; одоогоор MTA-STS нь MTA доторх хайрцагнаас дэмжигдээгүй байна.

MTA-STS нь итгэмжлэгдсэн эх CA-н жагсаалтыг ашигладаг.

MTA-STS нь халдагч хүчинтэй гэрчилгээ ашигладаг халдлагаас хамгаалахгүй. Ихэнх тохиолдолд серверийн ойролцоох MitM нь гэрчилгээ олгох чадварыг илэрхийлдэг. Ийм халдлагыг гэрчилгээний ил тод байдлыг ашиглан илрүүлж болно. Тиймээс ерөнхийдөө MTA-STS нь замын хөдөлгөөнд саад учруулах боломжийг багасгадаг боловч бүрэн арилгадаггүй.

Сүүлийн хоёр цэг нь MTA-STS-ийг SMTP-д зориулсан өрсөлдөгч DANE стандартаас (RFC 7672) аюулгүй байдал багатай болгодог боловч техникийн хувьд илүү найдвартай, i.e. MTA-STS-ийн хувьд стандартын хэрэгжилтээс үүссэн техникийн асуудлын улмаас захидал ирэхгүй байх магадлал бага байна.

Өрсөлдөгч стандарт - DANE

DANE нь гэрчилгээний мэдээллийг нийтлэхдээ DNSSEC-ийг ашигладаг бөгөөд гадны гэрчилгээний байгууллагад итгэх шаардлагагүй бөгөөд энэ нь илүү аюулгүй юм. Гэхдээ DNSSEC-ийг ашиглах нь хэд хэдэн жилийн ашиглалтын статистикт үндэслэн техникийн доголдолд хүргэдэг (хэдийгээр DNSSEC-ийн найдвартай байдал, түүний техникийн дэмжлэг ерөнхийдөө эерэг хандлагатай байдаг). Хүлээн авагч тал дээр SMTP-д DANE-г хэрэгжүүлэхийн тулд DNS бүсэд DNSSEC байх шаардлагатай бөгөөд DNSSEC-д системийн асуудал гардаг DANE-д NSEC/NSEC3-ийн зөв дэмжлэг зайлшгүй шаардлагатай.

Хэрэв DNSSEC зөв тохируулагдаагүй бол илгээгч тал DANE-г дэмждэг бол хүлээн авагч тал энэ талаар юу ч мэдэхгүй байсан ч энэ нь шуудан хүргэхэд алдаа гарахад хүргэдэг. Тиймээс, DANE нь хуучин бөгөөд илүү найдвартай стандарт бөгөөд илгээгчийн талд байгаа зарим серверийн програм хангамжид аль хэдийн дэмжигдсэн боловч үнэндээ түүний нэвтрэлт нь ач холбогдолгүй хэвээр байгаа ч DNSSEC-ийг хэрэгжүүлэх шаардлагатай байгаа тул олон байгууллага үүнийг хэрэгжүүлэхэд бэлэн биш байна. Энэ нь стандарт оршин тогтнож байсан DANE-ийн хэрэгжилтийг мэдэгдэхүйц удаашруулсан.

DANE болон MTA-STS нь хоорондоо зөрчилддөггүй бөгөөд хамтдаа ашиглах боломжтой.

Mail.ru Mail дээрх MTA-STS-ийн дэмжлэг юу вэ?

Mail.ru нь бүх гол домэйнуудад зориулсан MTA-STS бодлогыг нэлээд удаан хугацаанд нийтэлж байна. Одоогоор бид стандартын үйлчлүүлэгчийн хэсгийг хэрэгжүүлж байна. Бичиж байх үед бодлогыг блоклохгүй горимд хэрэгжүүлдэг (хэрэв хүргэлтийг бодлогоор хаасан бол захидлыг бодлого хэрэглэхгүйгээр "нөөц" серверээр дамжуулан хүргэх болно), дараа нь блоклох горимыг бага зэрэг шахах болно. гарч буй SMTP траффик, аажмаар траффикийн 100% байх болно Бодлогын хэрэгжилтийг дэмжинэ.

Стандартыг өөр хэн дэмждэг вэ?

Одоогийн байдлаар MTA-STS-ийн бодлого нь идэвхтэй домэйнуудын ойролцоогоор 0.05% -ийг нийтэлдэг боловч тэдгээр нь их хэмжээний захидлын урсгалыг аль хэдийн хамгаалдаг. Стандартыг Google, Comcast болон зарим хэсэг нь Verizon (AOL, Yahoo) зэрэг томоохон тоглогчид дэмждэг. Бусад олон шуудангийн үйлчилгээнүүд ойрын хугацаанд стандартад дэмжлэг үзүүлнэ гэж мэдэгдсэн.

Энэ нь надад хэрхэн нөлөөлөх вэ?

Таны домэйн MTA-STS бодлогыг нийтлэхгүй бол болохгүй. Хэрэв та бодлогыг нийтэлсэн бол таны имэйлийн серверийн хэрэглэгчдийн цахим шуудан саатуулахаас илүү сайн хамгаалагдах болно.

Би MTA-STS-ийг хэрхэн хэрэгжүүлэх вэ?

Хүлээн авагч талын MTA-STS-ийн дэмжлэг

Бодлогыг HTTPS-ээр нийтэлж, DNS-д бичлэг хийх, MTA дахь STARTTLS-д итгэмжлэгдсэн CA-уудын аль нэгний хүчинтэй гэрчилгээг тохируулах (Шифрлэх боломжтой) хийхэд хангалттай (STARTTLS орчин үеийн бүх MTA-д дэмжигддэг), тусгай дэмжлэг байхгүй MTA шаардлагатай.

Алхам алхмаар дараах байдалтай байна.

1. Өөрийн ашиглаж буй MTA (postfix, exim, sendmail, Microsoft Exchange гэх мэт) дээр STARTTLS-ийг тохируулна уу.
2. Та хүчинтэй гэрчилгээ ашиглаж байгаа эсэхээ шалгаарай (итгэмжлэгдсэн CA-аас олгосон, хугацаа нь дуусаагүй, гэрчилгээний сэдэв нь таны домэйнд имэйл хүргэдэг MX бичлэгтэй таарч байна).
3. Бодлогын хэрэглээний тайлангуудыг хүргэх TLS-RPT бичлэгийг тохируулна уу (TLS тайланг илгээхийг дэмждэг үйлчилгээнүүдээр). Жишээ оруулга (example.com домэйны хувьд):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   Энэ оруулга нь шуудан илгээгчдэд SMTP дахь TLS ашиглалтын статистик тайланг илгээхийг зааварчилдаг. [email protected].

   Алдаа байхгүй эсэхийг шалгахын тулд тайланг хэдэн өдрийн турш хяна.

4. MTA-STS бодлогыг HTTPS-ээр нийтлэх. Уг удирдамжийг байршлаар нь CRLF мөрийн төгсгөлөгчтэй текст файл хэлбэрээр нийтэлсэн.

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

   Жишээ бодлого:

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

   Хувилбарын талбар нь бодлогын хувилбарыг агуулж байна (одоогоор STSv1), Горим нь бодлогын хэрэглээний горимыг, тест хийх — туршилтын горимыг (бодлогыг хэрэгжүүлээгүй), хэрэгжүүлэх — "байлдааны" горимыг тохируулна. Эхлээд бодлогыг горимоор нийтлээрэй: тест хийх, хэрэв туршилтын горимд бодлогод асуудал гарахгүй бол хэсэг хугацааны дараа та: хэрэгжүүлэх горим руу шилжиж болно.

   mx-д таны домэйны имэйл хүлээн авах боломжтой бүх имэйл серверүүдийн жагсаалтыг зааж өгсөн болно (сервер бүр mx-д заасан нэртэй таарч тохируулсан гэрчилгээтэй байх ёстой). Max_age нь бодлогын кэшлэх хугацааг заадаг (хөдөлгөөнт этгээд дамжуулалтыг блоклох эсвэл кэш хийх явцад DNS бүртгэлийг гэмтээсэн ч санасан бодлого хэрэгжинэ, та mta-sts DNS-г өөрчилснөөр бодлогыг дахин шаардах шаардлагатайг дохиолж болно. бичлэг).

5. TXT бичлэгийг DNS дээр нийтлэх: 

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

   Дурын танигч (жишээ нь, цагийн тэмдэг) id талбарт ашиглагдаж болох бөгөөд бодлого өөрчлөгдөхөд энэ нь өөрчлөгдөх ёстой бөгөөд энэ нь илгээгчид кэшийн бодлогыг дахин шаардах шаардлагатай гэдгийг ойлгох боломжийг олгоно (хэрэв танигч нь кэшлэгдсэн).

Илгээгчийн талд MTA-STS-ийн дэмжлэг

Одоогоор түүнд муу байна, учир нь... шинэ стандарт.

• Exim - суурилуулсан дэмжлэг байхгүй, гуравдагч талын скрипт байдаг https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - суулгасан дэмжлэг байхгүй, гуравдагч талын скрипт байдаг бөгөөд үүнийг Habré дээр дэлгэрэнгүй тайлбарласан болно. https://habr.com/en/post/424961/

"Заавал TLS"-ийн тухай дараагийн үг

Сүүлийн үед зохицуулагчид имэйлийн аюулгүй байдалд анхаарлаа хандуулж байна (энэ нь сайн хэрэг). Жишээлбэл, DMARC нь АНУ-ын бүх төрийн байгууллагуудад заавал байх ёстой бөгөөд санхүүгийн салбарт шаардлага улам бүр нэмэгдэж, зохицуулалттай газруудад стандартын нэвтрэлт 90% хүрч байна. Одоо зарим зохицуулагчид "заавал TLS"-ийг бие даасан домэйнуудад хэрэгжүүлэхийг шаарддаг боловч "заавал TLS" -ийг баталгаажуулах механизм тодорхойлогдоогүй бөгөөд практикт энэ тохиргоог аль хэдийн хийгдсэн бодит халдлагаас бага ч гэсэн хамгаалдаггүй байдлаар хэрэгжүүлдэг. DANE эсвэл MTA-STS зэрэг механизмд заасан.

Зохицуулагч нь тусдаа домэйн бүхий "заавал TLS"-ийг хэрэгжүүлэхийг шаарддаг бол бид MTA-STS эсвэл түүний хэсэгчилсэн аналогийг хамгийн тохиромжтой механизм болгон авч үзэхийг зөвлөж байна, энэ нь домэйн тус бүрийн аюулгүй байдлын тохиргоог тусад нь хийх шаардлагагүй болно. Хэрэв танд MTA-STS-ийн үйлчлүүлэгчийн хэсгийг хэрэгжүүлэхэд бэрхшээлтэй байгаа бол (протокол өргөн хүрээний дэмжлэг авах хүртэл, тэд хамгийн их боломжтой байх болно) бид энэ аргыг санал болгож болно:

1. MTA-STS бодлого болон/эсвэл DANE бүртгэлийг нийтлэх (DANE нь зөвхөн таны домэйнд DNSSEC аль хэдийн идэвхжсэн тохиолдолд л утга учиртай бөгөөд ямар ч тохиолдолд MTA-STS) энэ нь таны чиглэлийн урсгалыг хамгаалж, бусад имэйл үйлчилгээнээс асуух шаардлагагүй болно. Хэрэв шуудангийн үйлчилгээ аль хэдийн MTA-STS болон/эсвэл DANE-г дэмждэг бол өөрийн домэйны заавал TLS-г тохируулах.
2. Томоохон имэйл үйлчилгээний хувьд MTA-STS-ийн "аналогийг" домэйн тус бүрд тусад нь тээвэрлэх тохиргоогоор хэрэгжүүлээрэй, энэ нь шуудан дамжуулахад ашигладаг MX-г засах бөгөөд үүнд TLS гэрчилгээг заавал баталгаажуулах шаардлагатай болно. Хэрэв домэйнууд MTA-STS бодлогыг аль хэдийн нийтэлсэн бол үүнийг өвдөлтгүй хийх боломжтой. Реле засах, гэрчилгээг баталгаажуулахгүйгээр домэйнд заавал TLS-г идэвхжүүлэх нь аюулгүй байдлын үүднээс үр дүнгүй бөгөөд одоо байгаа STARTTLS механизмд юу ч нэмдэггүй.

Эх сурвалж: www.habr.com