الخلاصة

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

حمل الرد صوتاً لم يطلبه العميل

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

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

أضاف RFC 6585 في عام 2012 الرمز 511 Network Authentication Required ليمنح هذا التدخل اسماً مستقلاً. معناه أن شرطاً لازماً للنفاذ إلى الشبكة لم يُستوفَ بعد. وهو يحدد أيضاً الجهة المتوقعة للرد: وكيل يعترض الاتصال ويسيطر على السماح به، لا الخادم الأصلي الذي قصده الطلب.

دخول الشبكة ليس تسجيل الدخول إلى الخدمة

قد تخفي كلمة «المصادقة» علاقتين مختلفتين. يحق للخدمة أن تتحقق من حساب قبل منح مورد تملكه. ويحق للشبكة أن تطلب دفعاً أو قبول شروط أو تسجيلاً قبل تمرير الحركة. القدرة على حجب الرزم لا تمنحها حق الكلام باسم الوجهة.

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

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

الرابط يفصل الهويات، والنموذج يخلطها

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

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

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

البرامج غير التفاعلية تكشف كلفة الاعتراض

يصف RFC 6585 الرمز 511 بوصفه تخفيفاً للضرر الذي تسببه بوابات النفاذ، وخصوصاً للوكلاء الذين ليسوا متصفحات. وهو لا يشجع الاعتراض.

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

كلما استُخدم HTTP أساساً لتطبيقات أكثر، عبرت سياسة الاستبدال حدوداً لا يعرفها مشغل الشبكة. يمنح الرمز المميز العملاء المستعدين سبباً لتعليق عمل الخادم الأصلي، بدلاً من تخزين محتوى خاطئ أو تغيير حالة أو تكرار الطلب بلا فهم.

لا يحق للتخزين المؤقت أن يمدد الأسر

يحظر تخزين ردود 511 مؤقتاً. فالحالة تخص شبكة بعينها وجلسة قبول ولحظة زمنية. لو حُفظ الرد فقد يبقى بعد السماح أو يرافق الجهاز إلى شبكة أخرى. والأسوأ أنه يعيد تقديم قول الوسيط بوصفه حالة للخادم الأصلي.

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

يكشف TLS الهوية المستعارة

في HTTP غير المشفر يستطيع الوسيط استبدال الرد وإرفاق 511. أما في HTTPS فيصادق العميل أولاً على اسم الخادم عبر TLS. لا تملك البوابة شهادة الخادم الأصلي المطلوب، ولذلك لا تستطيع إكمال المصافحة بصدق. ويشير RFC 6585 إلى أن اعتراض HTTPS يسبب خطأ في الشهادة.

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

وتتجاوز المخاطر الشهادات. قد يرى الوسيط بيانات مصادقة مرسلة في HTTP غير المشفر أو يتدخل في ملفات الارتباط التابعة لنطاق الخادم الأصلي. يؤكد RFC أن هذه المخاطر قائمة سواء استُخدم 511 أم لا. فالخطأ الأدق لا يحول المسار غير الآمن إلى قناة موثوقة.

من مفاجأة الاعتراض إلى حالة مهيأة مسبقاً

تفصل Captive Portal Architecture في RFC 8952 الأدوار. يخبر التهيئة جهاز المستخدم بموقع API، وتبلغ الواجهة عن الحالة، وتتولى بوابة المستخدم التفاعل، ويقرر جهاز الإنفاذ الحجب أو السماح. ويحدد RFC 8908 التبادل مع الواجهة عبر HTTPS.

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

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

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

حقيقة ضيقة يستطيع 511 حملها

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

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

المصادر