الخلاصة

  • توصي RFC 8314 باستخدام TLS الضمني للوصول إلى البريد وتقديمه؛ فعلى المنافذ 465 و993 و995 تبدأ المصافحة فور قيام اتصال TCP وقبل أوامر التطبيق.
  • يحمي هذا الترتيب إنشاء القناة، لكنه لا يثبت وحده هوية الخدمة المقصودة ولا يصادق المستخدم أو يمنحه حقوق صندوق أو إرسال، ولا يثبت قبول الرسالة أو تسليمها النهائي.

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

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

نشر كيث مور وكريس نيومان RFC 8314 عام 2018. اعتبرت الوثيقة استمرار النص الصريح بين Mail User Agent وخوادم الوصول أو تقديم البريد ممارسة ينبغي تجاوزها، وأوصت بـTLS الضمني لبروتوكولات POP وIMAP وSMTP Submission بدلاً من بدء جلسة تطبيق صريحة ثم رفعها بأمر STARTTLS أو ما يشبهه.

تعني كلمة «ضمني» توقيت البدء. عندما يتصل العميل بخدمة submissions على المنفذ الافتراضي 465 تبدأ مصافحة TLS مباشرة بعد TCP. ينطبق النموذج نفسه على 993 مع IMAP و995 مع POP. لا تبدأ أوامر البريد إلا بعد قيام القناة. أما STARTTLS فيبدأ بحوار تطبيق غير مشفر، يقرأ العميل خلاله القدرات ويطلب الترقية، ثم تأتي المصافحة.

إزالة مرحلة أوامر ما قبل TLS تقلص فرصة خفض الحماية. لكنها لا تجعل الرقم 465 برهاناً تشفيرياً. إعداد المنفذ لا يكشف العنوان الذي حُل فعلاً، ولا البرنامج الذي استجاب، ولا الشهادة التي ظهرت، ولا الاسم الذي تحقق منه العميل. يجب أن يسجل التحقيق الاتصال المنفذ، لا النية الموجودة في شاشة الإعدادات فقط.

لم تتجاهل RFC 8314 الواقع التشغيلي للمنفذ 587. فقد أقرت انتشار STARTTLS عليه، وأوصت خلال مرحلة انتقالية بدعم 587 مع الترقية و465 مع TLS الضمني. لذلك لا يجوز وصف كل استعمال لـSTARTTLS بأنه فاشل. يتوقف الخطر على سياسة العميل حين تختفي قدرة الترقية أو يفشل الأمر: هل ينهي الجلسة لأن TLS إلزامي، أم يواصل بلا حماية؟

كانت RFC 2595 قد عرّفت STARTTLS في IMAP وPOP3 وACAP، وشرحت قدرة وسيط مهاجم على إزالة الإعلان أو توليد فشل. غياب القدرة وحده لا يثبت الهجوم، إذ قد يكون اختلاف إعداد أو نسخة. كما أن استمرار الاتصال لا يثبت السلامة. يلزم جمع الرد الخام، وقاعدة العميل، والفعل الذي أعقب الفشل.

وتحتاج مصافحة TLS نفسها إلى اسم مرجعي. تلزم RFC 8314 العملاء بتنفيذ التحقق من الشهادة. وتعرض RFC 9525، وهي وثيقة أحدث لمؤلفين آخرين، الإطار العام الحالي لهوية الخدمة: يبني العميل معرفات مرجعية من إدخال أو إعداد موثوق، ويتحقق من مسار الشهادة، ثم يقارنها بالمعرفات المقدمة. الاسم الوسيط الناتج أثناء حل DNS لا يصبح تلقائياً هوية كان العميل يقصد توثيقها.

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

لا تلغي شهادة العميل هذا الحد. تسمح RFC 8314 للخادم بقبول شهادات العملاء، وتسمح له أيضاً بطلب مصادقة تطبيقية حتى بعد تقديم شهادة. ومن ثم لا تكفي مصافحة TLS متبادلة لإثبات تفويض أمر، ما لم يُسجل ربط الشهادة بالحساب والسياسة التي منحت ذلك الحساب حق الفعل.

يسمي SASL الفصل بوضوح. تميز RFC 4422 بين authentication identity المرتبطة ببيانات الاعتماد وauthorization identity التي يطلب العميل العمل باسمها. يتحقق الخادم من الأولى ويقرر هل يسمح لها بتمثيل الثانية. إذا فشلت المصادقة أو التفويض فشل التبادل. وطلب العمل بالهوية المصادق عليها نفسها لا يعفي الخادم من تطبيق السياسة.

يضيف تقديم الرسائل مساحة حقوق خاصة. تفصل RFC 6409 التقديم عن الترحيل وتحجز المنفذ 587 للخدمة. يستطيع Message Submission Agent قبول المستخدمين المصرح لهم فقط ورفض MAIL FROM لا يملك حقوقاً كافية أو لا ينسجم مع المصادقة. الوصول المشفر إلى MSA لا يوافق مسبقاً على المرسل أو المستقبلين أو الحجم أو المحتوى.

حتى قبول MSA ليس تسليماً نهائياً. إنه إيصال بأن الوكيل تحمل المسؤولية عند تلك النقطة. بعده تأتي عمليات النقل ورد الخادم المستقبل والمرشحات ووضع الرسالة في الصندوق وقراءتها. «نجح TLS» و«طابقت هوية الخدمة» و«صودق المستخدم» و«فُوض الأمر» و«قُبلت الرسالة» و«سُلّمت» نتائج مستقلة.

يحفظ السجل القابل لإعادة الفحص الترتيب كله: اسم الخدمة وإدخال الاكتشاف، والعنوان والمنفذ المتصل بهما، وطريقة بدء TLS، والمصافحة والنسخة والشهادة، ومسار الثقة والمعرفات المرجعية والمطابقة. ثم يسجل آلية SASL وهوية المصادقة وهوية التفويض المطلوبة والسياسة والأمر والرد الدقيق. وتأتي أدلة النقل والتسليم لاحقاً.

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

المصادر