باختصار، MTA-STS هي وسيلة لمزيد من الحماية لرسائل البريد الإلكتروني من الاعتراض (أي هجمات الرجل في الوسط المعروفة أيضًا باسم MitM) عند نقلها بين خوادم البريد. إنه يحل جزئيًا المشكلات المعمارية القديمة لبروتوكولات البريد الإلكتروني ويتم وصفه في المعيار الحديث نسبيًا RFC 8461. Mail.ru هي أول خدمة بريد رئيسية على RuNet تنفذ هذا المعيار. ويتم وصفه بمزيد من التفصيل تحت الخفض.

ما هي المشكلة التي تحلها MTA-STS؟

تاريخيًا، قامت بروتوكولات البريد الإلكتروني (SMTP، POP3، IMAP) بنقل المعلومات بنص واضح، مما جعل من الممكن اعتراضها، على سبيل المثال، عند الوصول إلى قناة اتصال.

كيف تبدو آلية تسليم الرسالة من مستخدم إلى آخر:

تاريخيًا، كان هجوم MitM ممكنًا في جميع الأماكن التي ينتشر فيها البريد.

يتطلب RFC 8314 استخدام TLS بين تطبيق مستخدم البريد (MUA) وخادم البريد. إذا كان الخادم الخاص بك وتطبيقات البريد التي تستخدمها متوافقة مع RFC 8314، فقد قمت (إلى حد كبير) بإزالة احتمالية هجمات Man-in-the-Middle بين المستخدم وخوادم البريد.

يؤدي اتباع الممارسات المقبولة عمومًا (الموحدة بواسطة RFC 8314) إلى القضاء على الهجوم بالقرب من المستخدم:

امتثلت خوادم بريد Mail.ru لـ RFC 8314 حتى قبل اعتماد المعيار؛ في الواقع، إنها ببساطة تلتقط الممارسات المقبولة بالفعل، ولم يكن علينا تكوين أي شيء إضافي. ولكن، إذا كان خادم البريد الخاص بك لا يزال يسمح للمستخدمين باستخدام بروتوكولات غير آمنة، فتأكد من تنفيذ توصيات هذا المعيار، لأنه على الأرجح، يعمل بعض المستخدمين على الأقل مع البريد دون تشفير، حتى لو كنت تدعمه.

يعمل عميل البريد دائمًا مع نفس خادم البريد لنفس المؤسسة. ويمكنك إجبار جميع المستخدمين على الاتصال بطريقة آمنة، ثم جعل من المستحيل تقنيًا على المستخدمين غير الآمنين الاتصال (وهذا هو بالضبط ما يتطلبه RFC 8314). وهذا أمر صعب في بعض الأحيان، ولكنه ممكن. لا تزال حركة المرور بين خوادم البريد أكثر تعقيدًا. تنتمي الخوادم إلى مؤسسات مختلفة وغالبًا ما يتم استخدامها في وضع "الضبط والنسيان"، مما يجعل من المستحيل التبديل إلى بروتوكول آمن مرة واحدة دون انقطاع الاتصال. يوفر SMTP منذ فترة طويلة امتداد STARTTLS، والذي يسمح للخوادم التي تدعم التشفير بالتبديل إلى TLS. لكن المهاجم الذي لديه القدرة على التأثير على حركة المرور يمكنه "قطع" المعلومات حول دعم هذا الأمر وإجبار الخوادم على التواصل باستخدام بروتوكول نص عادي (ما يسمى بهجوم الرجوع إلى إصدار أقدم). لنفس السبب، عادة لا يتحقق STARTTLS من صحة الشهادة (الشهادة غير الموثوقة يمكن أن تحمي من الهجمات السلبية، وهذا ليس أسوأ من إرسال رسالة بنص واضح). ولذلك، فإن STARTTLS يحمي فقط من التنصت السلبي.

تعمل MTA-STS على حل مشكلة اعتراض الرسائل بين خوادم البريد جزئيًا، عندما يكون لدى المهاجم القدرة على التأثير بشكل فعال على حركة المرور. إذا نشر نطاق المستلم سياسة MTA-STS وكان خادم المرسل يدعم MTA-STS، فلن يرسل البريد الإلكتروني إلا عبر اتصال TLS، فقط إلى الخوادم المحددة بواسطة السياسة، وفقط مع التحقق من شهادة الخادم.

لماذا جزئيا؟ تعمل MTA-STS فقط إذا حرص الطرفان على تنفيذ هذا المعيار، ولا تحمي MTA-STS من السيناريوهات التي يتمكن فيها المهاجم من الحصول على شهادة مجال صالحة من أحد المراجع المصدقة العامة.

كيف تعمل 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;"

مرسل

يطلب المرسل سجل DNS _mta-sts، وإذا كان متاحًا، يقدم طلب سياسة عبر HTTPS (التحقق من الشهادة). يتم تخزين السياسة الناتجة مؤقتًا (في حالة قيام مهاجم بحظر الوصول إليها أو انتحال سجل DNS).

عند إرسال البريد، يتم التأكد مما يلي:

• الخادم الذي يتم تسليم البريد إليه موجود في السياسة؛
• يقبل الخادم البريد باستخدام TLS (STARTTLS) ولديه شهادة صالحة.

مزايا MTA-STS

يستخدم MTA-STS التقنيات التي تم تنفيذها بالفعل في معظم المؤسسات (SMTP+STARTTLS، HTTPS، DNS). للتنفيذ على الجانب المتلقي، لا يلزم دعم برامج خاصة للمعيار.

عيوب MTA-STS

من الضروري مراقبة صحة شهادة خادم الويب والبريد وتطابق الأسماء والتجديد في الوقت المناسب. ستؤدي مشاكل الشهادة إلى عدم إمكانية تسليم البريد.

من ناحية المرسل، يلزم توفر MTA مع دعم لسياسات MTA-STS؛ حاليًا، MTA-STS غير مدعوم بشكل جاهز في MTA.

يستخدم MTA-STS قائمة المراجع المصدقة الجذرية الموثوقة.

لا تحمي MTA-STS من الهجمات التي يستخدم فيها المهاجم شهادة صالحة. في معظم الحالات، يعني MitM بالقرب من الخادم القدرة على إصدار شهادة. يمكن اكتشاف مثل هذا الهجوم باستخدام شهادة الشفافية. لذلك، بشكل عام، تعمل MTA-STS على تخفيف احتمالية اعتراض حركة المرور، ولكنها لا تلغيها تمامًا.

النقطتان الأخيرتان تجعلان MTA-STS أقل أمانًا من معيار DANE المنافس لـ SMTP (RFC 7672)، ولكنه أكثر موثوقية من الناحية الفنية، أي. بالنسبة لـ MTA-STS، هناك احتمال ضعيف بعدم تسليم الرسالة بسبب مشاكل فنية ناجمة عن تنفيذ المعيار.

المعيار التنافسي - DANE

تستخدم DANE DNSSEC لنشر معلومات الشهادة ولا تتطلب الثقة في مراجع الشهادات الخارجية، وهو أكثر أمانًا. لكن استخدام DNSSEC يؤدي في كثير من الأحيان إلى أعطال فنية، بناءً على الإحصائيات على مدار عدة سنوات من الاستخدام (على الرغم من وجود اتجاه إيجابي بشكل عام في موثوقية DNSSEC ودعمه الفني). لتنفيذ DANE في SMTP على الجانب المتلقي، يعد وجود DNSSEC لمنطقة DNS إلزاميًا، ويعد الدعم الصحيح لـ NSEC/NSEC3 ضروريًا لـ DANE، حيث توجد مشكلات نظامية في DNSSEC.

إذا لم يتم تكوين DNSSEC بشكل صحيح، فقد يؤدي ذلك إلى فشل تسليم البريد إذا كان الجانب المرسل يدعم DANE، حتى لو كان الجانب المتلقي لا يعرف شيئًا عن ذلك. لذلك، على الرغم من أن DANE هو معيار أقدم وأكثر أمانًا ومدعوم بالفعل في بعض برامج الخادم من جانب المرسل، إلا أن اختراقه في الواقع لا يزال ضئيلًا، والعديد من المنظمات ليست مستعدة لتنفيذه بسبب الحاجة إلى تنفيذ DNSSEC، وقد أدى هذا إلى تباطؤ كبير في تنفيذ DANE طوال تلك السنوات التي كان فيها المعيار موجودًا.

لا يتعارض DANE وMTA-STS مع بعضهما البعض ويمكن استخدامهما معًا.

ما هو دعم MTA-STS في Mail.ru Mail؟

لقد قام Mail.ru بنشر سياسة MTA-STS لجميع النطاقات الرئيسية لبعض الوقت. نقوم حاليًا بتنفيذ جزء العميل من المعيار. في وقت الكتابة، يتم تطبيق السياسات في وضع عدم الحظر (إذا تم حظر التسليم بواسطة سياسة، فسيتم تسليم الرسالة من خلال خادم "احتياطي" دون تطبيق السياسات)، ثم سيتم فرض وضع الحظر لجزء صغير من حركة مرور SMTP الصادرة، سيتم دعم تنفيذ السياسات تدريجيًا بالنسبة لـ 100% من حركة المرور.

من آخر يدعم هذا المعيار؟

حتى الآن، تنشر سياسات MTA-STS ما يقرب من 0.05% من النطاقات النشطة، ولكنها مع ذلك تحمي بالفعل حجمًا كبيرًا من حركة مرور البريد، لأن المعيار مدعوم من قبل اللاعبين الرئيسيين - Google وComcast وجزئيًا Verizon (AOL وYahoo). أعلنت العديد من الخدمات البريدية الأخرى أنه سيتم تنفيذ دعم المعيار في المستقبل القريب.

كيف سيؤثر ذلك علي؟

ليس إلا إذا قام نطاقك بنشر سياسة MTA-STS. إذا قمت بنشر السياسة، فستكون رسائل البريد الإلكتروني لمستخدمي خادم البريد الخاص بك محمية بشكل أفضل من الاعتراض.

كيف أقوم بتنفيذ MTA-STS؟

دعم MTA-STS على الجانب المتلقي

يكفي نشر السياسة عبر HTTPS والسجلات في DNS، وتكوين شهادة صالحة من أحد المراجع المصدقة الموثوقة (دعونا نقوم بالتشفير ممكن) لـ STARTTLS في MTA (يتم دعم STARTTLS في جميع MTAs الحديثة)، ولا يوجد دعم خاص من مطلوب MTA.

خطوة بخطوة، يبدو الأمر كما يلي:

1. قم بتكوين STARTTLS في MTA الذي تستخدمه (postfix، وexim، وsendmail، وMicrosoft Exchange، وما إلى ذلك).
2. تأكد من أنك تستخدم شهادة صالحة (صادرة عن مرجع مصدق موثوق به، وليست منتهية الصلاحية، وموضوع الشهادة يطابق سجل MX الذي يسلم البريد للمجال الخاص بك).
3. قم بتكوين سجل TLS-RPT الذي سيتم من خلاله تسليم تقارير تطبيق السياسة (من خلال الخدمات التي تدعم إرسال تقارير TLS). مثال على الإدخال (للنطاق example.com):

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

   يرشد هذا الإدخال مرسلي البريد إلى إرسال تقارير إحصائية حول استخدام TLS في SMTP إلى [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;”
   

   يمكن استخدام معرف عشوائي (على سبيل المثال، الطابع الزمني) في حقل المعرف؛ عندما تتغير السياسة، يجب أن تتغير، وهذا يسمح للمرسلين بفهم أنهم بحاجة إلى إعادة طلب السياسة المخزنة مؤقتًا (إذا كان المعرف مختلفًا عن مخبأة واحدة).

دعم MTA-STS من جانب المرسل

حتى الآن الأمر سيء معها، لأن... معيار جديد.

• Exim - لا يوجد دعم مدمج، هناك برنامج نصي لجهة خارجية https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - لا يوجد دعم مدمج، بل يوجد نص برمجي لجهة خارجية تم وصفه بالتفصيل على حبري 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 على أي حال)، سيؤدي ذلك إلى حماية حركة المرور في اتجاهك وإلغاء الحاجة إلى طلب خدمات بريد إلكتروني أخرى لتكوين TLS الإلزامي لنطاقك إذا كانت خدمة البريد تدعم بالفعل MTA-STS و/أو DANE.
2. بالنسبة لخدمات البريد الإلكتروني الكبيرة، قم بتنفيذ "تناظري" لـ MTA-STS من خلال إعدادات نقل منفصلة لكل نطاق، مما سيؤدي إلى إصلاح MX المستخدم لترحيل البريد وسيتطلب التحقق الإلزامي من شهادة TLS له. إذا كانت النطاقات تنشر بالفعل سياسة MTA-STS، فمن المحتمل أن يتم ذلك دون عناء. في حد ذاته، يعد تمكين TLS الإلزامي للمجال دون إصلاح الترحيل والتحقق من الشهادة الخاصة به غير فعال من وجهة نظر أمنية ولا يضيف أي شيء إلى آليات STARTTLS الحالية.

المصدر: www.habr.com