الخلاصة

  • بعد نجاح TLS أو SASL، اعتبر XMPP تدفق XML السابق مستبدلاً من غير إرسال وسم الإغلاق المعتاد </stream> ومن غير إنهاء اتصال TCP الكامن.
  • حمل التدفق الجديد ترويسة ومعرّفاً وقائمة خصائص تناسب المرحلة الجديدة؛ وبقي بقاء TCP والتشفير والتحقق من الطرف ونجاح SASL وربط المورد وقبول المقطع حقائق مستقلة.

كانت رسالة النجاح نهايةً للسياق الذي حملها

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

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

يحدث انتقال مشابه عندما يرسل الخادم <success/> في SASL. تثبت الرسالة نجاح تبادل المصادقة، لكنها لا تمنح التدفق الذي حملها عمراً جديداً. يفتح العميل تدفقاً آخر فوق اتصال TCP نفسه، وعندئذ تظهر الخصائص التي لا معنى لها إلا بعد المصادقة.

استمر الناقل، بينما تغيرت اللغة التي تفسر ما يمر عليه. وهذه ليست مفارقة شكلية؛ إنها طريقة لمنع الحقائق القديمة من اكتساب قوة لم تكن لها عند وصولها.

كان لكل طبقة زمنها الخاص

يفصل RFC 6120 بين اتصال TCP وتدفق XML. TCP ثنائي الاتجاه، أما تدفق XMPP الواحد فهو أحادي الاتجاه بالمعنى الدقيق، ويستخدم الطرفان عادة تدفقين متعاكسين للتواصل.

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

لذلك ليست العملية إعادة اتصال. إنشاء TCP جديد سيعيد بناء ارتباط النقل ويجلب معه ظروف مسار وحالة جديدة. هنا ظل المسار قائماً، بينما مُسحت ذاكرة التفاوض في طبقة التطبيق.

وليست العملية استئنافاً للرسائل أو إثباتاً لتسليمها. لا يقول restart إن المقاطع السابقة وصلت أو إنها ستعاد، ولا إنه يعيد حالة تطبيق بعيد. إنه يحدد فقط الجيل الذي ستفسر ضمنه بيانات XML اللاحقة.

لم تكن الخصائص قائمة قدرات ثابتة

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

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

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

حتى الغياب محدود الدلالة. قد لا يحين وقت الخاصية بعد، أو تكون قد استُهلكت، أو تمنعها السياسة. ويضيف RFC 7590 أن مهاجماً يستطيع إزالة إعلان STARTTLS أو العنصر required. ما شوهد على المسار دليل على ما وصل، لا جرد كامل لقدرات الخادم.

لم يحم TLS الماضي بأثر رجعي

بعد نجاح TLS، يطلب RFC 6120 من الجانبين التخلص من المعلومات التي حصلا عليها بصورة غير آمنة فوق TCP قبل بدء الحماية. وتشمل الأمثلة عنوان from القديم، ومعرّف التدفق، والخصائص المعروضة.

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

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

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

أثبت SASL الاعتماد ولم يمنح تفويضاً مطلقاً

يقدم RFC 4422 ‏SASL إطاراً لآليات مصادقة قابلة للاستبدال. ويفصل بين هوية المصادقة وهوية التفويض ونتيجة التبادل وطبقة أمن البيانات التي قد تنشئها بعض الآليات. لا توفر كل آلية الخصائص نفسها.

يحمّل XMPP هذا التبادل داخل XML، ثم يفرض تدفقاً جديداً بعده. تقول <success/> إن الآلية المختارة نجحت؛ ولا تقول إن كل متطلبات XMPP اكتملت أو إن العميل يستطيع مخاطبة أي وجهة.

يبقى ربط المورد إلزامياً لعميل متصل بخادم. لا يعرض الخادم <bind/> إلا في التدفق اللاحق لـSASL. يربط هذا الإجراء resourcepart بالحساب والتدفق، ويميّز مورداً متصلاً من موارد أخرى للحساب ذاته.

إذا أرسل العميل قبل الربط مقطعاً إلى جهة غير الخادم أو حسابه، فعلى الخادم ألا يعالجه وأن يغلق التدفق بخطأ not-authorized. قد يكون TCP حياً وTLS صحيحاً وSASL ناجحاً، بينما يظل مسار التطبيق غير جاهز.

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

منع المعيار إعادة الفتح بعد ربط المورد

ينص RFC 6120 صراحة على أن الطرفين لا يعيدان فتح التدفق بعد resource binding. تكشف هذه القاعدة السلبية أن XMPP لم يجعل كل نجاح سبباً آلياً للاستبدال.

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

لذلك لا تكفي قاعدة برمجية تقول «إذا نجح التفاوض، افتح تدفقاً جديداً». عدم الفتح بعد TLS خطأ، وعدم الفتح بعد SASL خطأ، والفتح بعد الربط قد يكون خطأ أيضاً. لا بد للحالة أن تعرف سبب كل حد.

وتبقى الأدلة محدودة: معرّف التدفق يربط جيلاً من XML ولا يثبت شخصاً؛ resourcepart يميز مورداً متصلاً ولا يصبح رمز تفويض دائم؛ وقبول مقطع محلياً لا يثبت تسليمه أو أثره.

بدأ التسلسل عام 2004 واتضح نموذجه عام 2011

كان RFC 3920، الصادر في أكتوبر 2004، يفرض تدفقاً جديداً بعد نجاح TLS وبعد نجاح SASL. كما وضع الطبقات بترتيب TCP ثم TLS ثم SASL ثم XMPP، واعتبر التدفق الأصلي منتهياً عند نقطتي النجاح من غير حاجة إلى وسم الإغلاق.

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

ثم حدّث RFC 7590 إرشادات TLS عام 2015 لمواجهة تهديدات أكثر نضجاً. وهو يذكر بأن تنفيذ التسلسل الصحيح لا يضمن وحده جودة الخوارزميات أو التحقق أو مقاومة التخفيض.

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

المصادر