الخلاصة

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

في QUIC كان الاسم بحاجة إلى وسيلة نقل مناسبة

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

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

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

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

كان منفذ واحد يستضيف أكثر من لغة

حين كان رقم المنفذ يرتبط عادة بتطبيق واحد، أمكن توقع محلل البروتوكول من العنوان والرقم. ومع اجتماع تطبيقات عديدة داخل TLS، خصوصاً على 443، لم يعد الرقم كافياً.

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

RFC 7301 تعرّف قائمة من المعرّفات المبهمة غير الفارغة في ClientHello. يجيب الخادم باسم واحد. وعند بدء بيانات التطبيق تكون صيغة البروتوكول محددة لهذا الاتصال.

تروي RFC 8170 أن HTTP/2 احتاج الآلية لتجنب جولة أخرى في النسخة المحمية بـ TLS، بينما استُخدمت آلية ترقية البروتوكول في النسخة غير المحمية. ثم أصبح ALPN الطريق الرئيس للتفاوض على نسخ HTTP اللاحقة.

ترقية البروتوكول تبدّل لغة اتصال HTTP قائم بعد الطلب والإجابة. أما ALPN فيختار قبل أول رسالة تطبيقية. تشابه الغرض لا يلغي اختلاف موضع القرار وحدوده.

العرض المرتب لم يكن أمراً ملزماً

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

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

الجواب قيمة واحدة، وتصبح نهائية للاتصال. لا يجوز إعلان h2 ثم تمرير HTTP/1.1. فالاختيار ليس منشوراً عاماً عن قدرات الخادم؛ إنه التزام يحدد معنى البايتات التالية.

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

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

الجلسة القديمة لم تكن صاحبة القرار الجديد

يسمح استئناف جلسة TLS وتذاكرها باختصار عمل تشفيري سبق إنجازه. لكن RFC 7301 تنص على أن ALPN خاص بالاتصال لا بالجلسة. عند الاستئناف يصبح محتوى التفاوض السابق غير ذي صلة؛ ما يعتد به هو المصافحة الجديدة.

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

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

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

TLS 1.3 غيّرت من يرى جواب الخادم

وضعت RFC 7301 عرض العميل في ClientHello واختيار الخادم في ServerHello وفق بنية TLS آنذاك. كان المؤشر مرئياً لأجهزة الشبكة حين لا يكشف المنفذ عن التطبيق، وحذرت الوثيقة من المعرّفات التي قد تسمح بالتنميط.

في RFC 8446 ينتقل جواب الخادم إلى EncryptedExtensions، وهي أول رسالة من الخادم تحميها مفاتيح حركة المصافحة. يبقى عرض العميل في ClientHello المعتاد.

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

هذا التغير في الرؤية لا يغير الملكية: حتى الجواب المحمي يولد في الاتصال الجديد ولا يسكن التذكرة القديمة.

HTTP/2 أثبت الاختيار ثم بدأ بمقدمة الاتصال

RFC 9113 تجعل h2 معرّفاً لـ HTTP/2 فوق TLS وتفرض ALPN. أما h2c فيصف الصيغة غير المحمية ولا يجوز عرضه أو اختياره في TLS ALPN.

بعد انتهاء TLS يرسل طرفا الاتصال مقدمة الاتصال. يحدد ALPN صيغة البروتوكول المسموح لها أن تبدأ؛ وتؤكد مقدمة الاتصال أن التطبيق المتصل بدأ فعلاً بصيغة البروتوكول هذه، وتحدد SETTINGS الأولية.

إذا اختارت عقدة طرفية h2 ثم مررت التدفق إلى خدمة داخلية لا تفهمه، تنجح المصافحة وتفشل مقدمة الاتصال. سجل واحد بعنوان “HTTP/2 مفعّل” يخفي موضع الخلل. يلزم ربط اختيار TLS بأول البايتات التطبيقية.

والاختيار لا يحل محل التفويض أو شهادة الاسم أو HTTP 421. إنه يحدد نوع الحديث، لا من يحق له الكلام باسم أي مصدر.

البيانات المبكرة لا تعبر تغير اللغة آلياً

تسمح TLS 1.3 في بعض عمليات الاستئناف بإرسال 0-RTT قبل اكتمال المصافحة. تكون البايتات قد أُعدت وفق توقع من الاتصال السابق.

تحظر RFC 8446 إعادة إرسال البيانات المبكرة آلياً ما لم يختَر الاتصال الجديد قيمة ALPN نفسها. فلا يجوز نقل إطار صيغ لـ HTTP/2 إلى اتصال اختار HTTP/1.1 لمجرد أن التذكرة واحدة.

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

السجل يثبت التخصيص لا الانتشار

يحفظ سجل IANA لامتدادات TLS ومعرّفات ALPN الامتداد من النوع 16 وأسماء البروتوكولات تحت المراجعة المتخصصة. يتضمن http/1.1 وh2 وh3، ويحفظ h2c مع منعه في TLS ALPN.

يمنع السجل التطبيقات المستقلة من أن تخترع بايتات مختلفة للاسم نفسه. لكنه لا يثبت أن العملاء يعرضونه أو أن الخوادم تختاره أو أن حركة الشبكة تستعمله أو أن التطبيق آمن.

توجد طبقات دليل مستقلة: السجل للاسم، المصافحة للاختيار، مقدمة الاتصال لتنفيذ صيغة البروتوكول، ونظام التفويض للفعل. قوة ALPN جاءت من عدم ادعاء أنها تؤدي وظائف الطبقات كلها.

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

المصادر

تحدد هذه المصادر معايير وتوصيات وسجلاً، ولا تقدم تعداداً حديثاً للانتشار أو حصة الحركة.