الخلاصة

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

إعداد كامل في سطر واحد

لم يكن اسم المستخدم كافياً لفتح صندوق POP3. احتاج البرنامج إلى خادم، وربما منفذ غير افتراضي، وهوية الصندوق، وطريقة للمصادقة. صاغ RFC 2384 هذه العناصر في الشكل العام pop://<user>;auth=<auth>@<host>:<port>.

كان المضيف هو العنصر الوحيد الإلزامي. عند حذف المنفذ أصبحت القيمة 110. أمكن ذكر الهوية والآلية أو تركهما. وأمكن ترميز المحارف التي لا تدخل مباشرة في صيغة الرابط. وهكذا صار من الممكن نقل نية الإعداد في سلسلة واحدة.

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

غياب كلمة المرور عن الرابط لا يمنع حركتها بسببه

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

ومع ذلك قد يحتفظ العميل بكلمة مرور من جلسة سابقة، أو يطلبها من المستخدم عند فتح الرابط. وقد يستخدم APOP أو يستدعي AUTH مع آلية SASL. لذلك يستطيع رابط لا يحتوي سراً أن يصبح سبباً في إرسال السر.

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

السؤال لم يكن فقط: ماذا يوجد داخل السلسلة؟ بل: ما الأصول الداخلية التي ستحركها البرمجية لأن جهة ما قدمت لها هذه السلسلة؟

هوية التفويض ليست هوية المصادقة

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

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

أما AUTH=* ففتح مجال الاختيار. يختار العميل آلية مناسبة من الآليات التي يدعمها الخادم. والأدق أن وجود اسم مستخدم من دون آلية كان يعني ضمناً هذا البدل. قد تخفي الصيغة الأقصر قدراً أكبر من السياسة غير المكتوبة.

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

خمسة أسس لعبور حد بيانات الاعتماد

لم يدّع RFC 2384 أن قواعد الصياغة تصنع الثقة. حدد خمسة شروط، يكفي أن يتحقق واحد منها قبل استخدام المصادقة التي يطلبها الرابط.

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

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

يملك كاتب الرابط اقتراح الوجهة. لا يمنحه ذلك تلقائياً السيطرة على مخزن أسرار العميل. قابلية نقل الإعداد لا تعني قابلية نقل السلطة.

الرابط المطلق ليس رابطاً مأذوناً

منع RFC روابط POP النسبية. لم يسمح لمرجع صندوق البريد بأن يرث مضيفه من عنوان أساس في وثيقة محيطة؛ كان عليه التصريح بوجهة مطلقة. أزال ذلك نوعاً من غموض التحليل.

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

لذلك يلزم إيصالان: ما الذي استخرجه المحلل، وما الدليل الذي سمح لبيانات الاعتماد بالذهاب إلى تلك الوجهة. لا يجوز أن يحل الأول محل الثاني.

مثالان صححهما التنفيذ

تجعل تصويبات RFC 2384 هذا الحد قابلاً للقياس. عرض مثال APOP بصمة لا تطابق تحدي الخادم وكلمة المرور الظاهرين في المثال نفسه. قدم Errata 2943، وهو موثق، القيمة الصحيحة. واستخدم مثال آخر اسم SCRAM-MD5، بينما كانت الآلية ذات الصلة آنذاك CRAM-MD5. أبقي Errata 2942 لتحديث الوثيقة لأن تصحيح الاسم يقتضي أيضاً إعادة بناء التبادل المرمز.

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

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

طبقة مشتركة رقيقة

حافظ POP3 على بساطته المقصودة. فصل RFC 1939 حالات التفويض والمعاملة والتحديث. عرّف RFC 1734 أمر AUTH، ووضع RFC 2222 إطار SASL، ثم أضاف RFC 2449 إعلان القدرات. لم يحاول RFC 2384 تحويل الرابط إلى بديل عن كل ذلك.

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

أتاحت هذه البنية نقل الإعداد من دون نقل السلطة معه. أمكن للعملاء فهم الصيغة نفسها مع الاحتفاظ بحدود أمن مختلفة.

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

سهّل RFC 2384 تسمية صندوق البريد. وكانت حكمته الأبعد ألا يحول الاسم إلى مطالبة بالمفتاح.

المصادر