الخلاصة

  • جعل RFC 1459 السابقة تسمّي مصدر الرسالة داخل IRC، لكن الخادم كان يبحث عن المصدر في قاعدته ويتحقق من تسجيله خلف وصلة الوصول نفسها.
  • تفرد اللقب وتسجيل العميل وصحة الفرع وقبول الرسالة حالات منفصلة؛ ولا واحدة منها تثبت الشخص الذي كتب الكلام.
  • كان عدم التطابق يؤدي إلى إسقاط صامت، لذلك لا يمكن تفسير غياب رسالة لاحقاً من نصها وحده، بل يلزم حفظ حالة الخادم والاتصال والوقت والقرار.

كانت كل قفزة تملك نسخة من الحقيقة

صدر RFC 1459 في مايو 1993 بصفة بروتوكول تجريبي. كان IRC قد نما من محادثة على نظام لوحات إعلانات إلى شبكة عالمية من العملاء والخوادم. حملت الواجهة رسائل نصية قصيرة، بينما كوّنت الخوادم شجرة تتولى تحديد العملاء وتمرير الرسائل.

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

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

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

الأصل البروتوكولي لم يكن توقيع إنسان

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

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

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

التفرد كان خاصية للسجل الحالي

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

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

قدّم WHOWAS تاريخاً قريباً للألقاب، كما تتبعت الخوادم تغييرات الاسم كي لا تصيب أوامر KILL وMODE وKICK الهدف الخطأ أثناء السباق. ومع ذلك اعترف النص بأن الخطأ يمكن أن يبقى. الاسم بلا وقت وجلسة ليس استمرارية شخصية.

الانقسام غيّر السجل الذي تجري عليه المطابقة

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

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

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

فصل عام 2000 جعل العقوبة أوضح

عرض RFC 2810 المعمارية مستقلة، وعدّ احتفاظ كل خادم بنسخة من الحالة العالمية عائقاً بارزاً أمام التوسع. كانت تلك النسخة نفسها أساس فحص المصدر.

أبقى RFC 2812 قاعدة العميل: غياب السابقة يعني اتصال الوصول، وحضورها من عميل لا يسمح إلا بلقبه المسجل. أما RFC 2813 ففصّل اتصال الخوادم. المصدر غير الموجود يُسقط؛ وإذا ادعت السابقة خادماً مجهولاً فقد تُقطع الوصلة. وإذا أشارت القاعدة إلى أن المصدر خلف وصلة أخرى، تُهمل الرسالة دائماً وقد يتبعها KILL للعميل أو قطع للرابط.

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

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

صححت الصيانة بايتاً من غير محو الأصل

كتب RFC 1459 قيمة النقطتين خطأ على أنها 0x3B، وهي قيمة الفاصلة المنقوطة. كان المحرف الظاهر والنحو يبينان المقصود، وصحح erratum 4091 المتحقق منه القيمة إلى 0x3A.

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

حمى TLS حداً آخر

انتقلت أوامر PASS وOPER بنص واضح في التصميم اللاحق الموصوف، فاقترح RFC 2813 تشفير طبقة التدفق مثل TLS. وسجل RFC 7194 لاحقاً منفذاً افتراضياً لـ IRC عبر TLS/SSL.

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

قدم RFC 1459 ضماناً أضيق: قبل أن يتصرف الخادم باسم مكتوب، تحقّق من العلاقة التي تسمح بظهوره. بقيت هوية الإنسان وسرية المحتوى والوصول النهائي حقائق أخرى.