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

ما المشكلة التي تحلها 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 من السيناريوهات التي تتاح فيها للمهاجم فرصة الحصول على شهادة مجال صالحة في أحد المراجع المصدقة (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;"

المرسل



يطلب المرسل سجل 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 إلزامي ، وبالنسبة لـ DANE ، يعد الدعم الصحيح لـ NSEC / NSEC3 أمرًا ضروريًا ، حيث يواجه 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. , ( CA, , MX-, ).
3. TLS-RPT , ( TLS). ( example.com):
   
   
   
   

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

   
   
   TLS SMTP tlsrpt@exmple.com.
   
   
   
   , .
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
   

   
   
   version ( STSv1), Mode , testing — ( ), enforce — «» . mode: testing, , mode: enforce.
   
   
   
   mx , ( , mx). Max_age ( DNS- , mta-sts DNS).
5. انشر سجل TXT على DNS: 
   
   
   
   

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

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

دعم 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 في أي حال) ، سيؤدي ذلك إلى حماية حركة المرور في اتجاهك وإلغاء الحاجة إلى مطالبة خدمات البريد الأخرى بتهيئة TLS الإلزامية لنطاقك إذا كانت الخدمة البريدية تدعم بالفعل MTA-STS و / أو DANE.
2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.