الخلاصة

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

من يضيف البيانات ليس دائما من يتحمل رفضها

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

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

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

RFC9440، المنشور في يوليو 2023 ضمن فئة Informational لدى IETF، يصف حقول نقل شهادة العميل في هذا النوع من النشر. هو ليس وثيقة من مسار Internet Standards Track. الغرض منه تقنين ممارسة قائمة لتسهيل التشغيل البيني بين مكونات مستقلة، لا اعتماد قدرة بيئة إنتاج أو تقديم نتيجة قياس أداء.

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

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

ما الذي تعنيه كلمة «الحجم»؟

يحمل Client-Cert شهادة الكيان النهائي، ويرسل الوكيل سلسلة التحقق عند اختيار ذلك عبر Client-Cert-Chain. تمثل الشهادات المرمزة بصيغة DER كقيم Byte Sequence ضمن Structured Fields. تظهر في الحقل النصي بصيغة base64 تحيط بها علامة النقطتين الرأسيتين من الجانبين، من دون مسافات أو فواصل أسطر داخل الترميز.

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

هناك أيضا مرحلتان مختلفتان قد تسميان «فك الترميز». يعيد HPACK أو QPACK إنشاء أسماء الحقول وقيمها النصية من تمثيل مضغوط. تظل قيمة الشهادة base64 عند هذه المرحلة. تحويلها لاحقا إلى DER ثنائي ليس العملية نفسها. لا يجوز استبدال حجم الحقول بعد فك ضغط HTTP بحجم الشهادة بعد فك base64 عند تقييم القيد النصي.

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

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

قدرة المحلل لا تلزم الخادم بقبول الرسالة كاملة

توضح Structured Fields الفارق بحد يخص نوع البيانات نفسه. يطلب RFC8941 وخلفه RFC9651 من محللات Byte Sequence دعم ما لا يقل عن 16,384 بايتا ثماني البتات بعد فك الترميز الثنائي. هذه قدرة تحليل للقيمة، وليست التزاما على خادم HTTP بقبول طلب كامل يحتوي على قيمة بذلك الحجم وسلسلة وحقول أخرى مهما كانت سياسته.

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

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

لكل إعلان طرف يطبقه

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

في HTTP/2 يحمل المعامل اسم SETTINGS_MAX_HEADER_LIST_SIZE. وفق RFC9113، هو إعلان إرشادي يحسب أطوال الأسماء والقيم غير المضغوطة، مضافا إليها 32 بايتا ثماني البتات لكل سطر حقل. يمكن للمستقبل فرض حد أصغر على طلب محدد من القيمة المعلنة. القيمة الابتدائية غير المحدودة لا تثبت أن التطبيقات أو المسارات الفعلية ذات قدرة غير محدودة.

في HTTP/3 يختلف الاسم إلى SETTINGS_MAX_FIELD_SECTION_SIZE. يحسب RFC9114 أيضا الأسماء والقيم غير المضغوطة مع 32 بايتا إضافيا لكل حقل. ينبغي للطرف الذي تلقى المعامل تجنب تجاوزه، لكن القيود تطبق بصورة مستقلة في كل تنفيذ يعالج الرسالة. وجود وسطاء يعني أن البقاء تحت إعلان واحد لا يضمن القبول عند الطرف التالي.

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

حجز الزيادة قبل وقوعها

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

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

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

اختيار السلسلة الاختيارية لا يعني إخفاء غيابها

Client-Cert حقل للطلبات فقط، يحمل شهادة الكيان النهائي كقيمة مفردة، ولا يسمح بقائمة أو تكرار. أما Client-Cert-Chain فهو قائمة اختيارية من Byte Sequences بالترتيب المستخدم في TLS. لا يعيد شهادة الحقل الأول، ولا يجوز ظهوره من دون ذلك الحقل.

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

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

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

جدول أوسع لا يجعل التطبيق ملزما برسالة أكبر

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

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

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

في QPACK يقيد RFC9204 الحد الأقصى للسعة الديناميكية بما يعلنه المفكك عبر SETTINGS_QPACK_MAX_TABLE_CAPACITY. يمنع الحد الأقصى الصفري إدراج مداخل في الجدول. هذا معامل غير حد حجم قسم الحقول في HTTP/3، ولا يعني انعدام كل أشكال الضغط. لا تدعي الدراسة أن QPACK يحجب بالضرورة طلبات الشهادات، ولا تصف إعدادا واحدا مطلوبا للجميع.

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

تقليل الرسالة ليس حفظ معناها

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

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

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

ذاكرة الاستجابات ليست جدول الضغط

إذا اختيرت الاستجابة بناء على Client-Cert، يطلب RFC9440 جعلها غير قابلة للتخزين المؤقت أو تقييد إعادة استخدامها بالطلبات ذات القيمة نفسها بواسطة Vary: Client-Cert. ويوصي RFC9440 الوكيل الذي ينهي TLS بتغيير قيمة Vary إلى * عند ظهور حقول الشهادات فيه، لمنع التخزين المؤقت لدى وكيل المستخدم. أما استجابات 431 فلا يجوز تخزينها مؤقتا.

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

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

المصادر وحدود الاستنتاج

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