الخلاصة

  • لا يبدأ HelloRetryRequest تفاوض TLS 1.3 من جديد. يجب أن تكرر رسالة ClientHello الثانية الأولى، باستثناء قائمة ضيقة من التغييرات المصرح بها، مثل مساهمة المفتاح المطلوبة، وحذف early data، وإعادة cookie، وإعادة حساب binders.
  • يستبدل البروتوكول بايتات ClientHello1 برسالة تركيبية من نوع message_hash تحمل ملخصها، ثم يوثق هذا الالتزام مع طلب الإعادة والرسائل اللاحقة. التشغيل عديم الحالة يضغط التاريخ ولا يمحوه.
  • ينبغي للدليل التشغيلي حفظ رسالتي ClientHello، وسبب الطلب، والفارق المسموح، وسياسة cookie، والمجموعة النهائية، والتنبيهات، والزمن الإضافي. نجاح المصافحة لا يثبت وحده سلامة الطلب ولا أن المجموعة النهائية كانت تفضيل العميل الأول.

التقاط بدأ بعد فوات الجزء الحاسم

بدا التشخيص مباشراً. أرسلت ClientHello2 مساهمة مفتاح واحدة، واختارت ServerHello المجموعة نفسها، ثم نجحت CertificateVerify وFinished من دون تنبيه. لخّصت لوحة المراقبة الحدث بعبارة: عرض العميل المجموعة فقبلها الخادم.

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

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

تصحيح تحكمه قائمة سماح مغلقة

تفرض مواصفة TLS 1.3 الحالية أن تبقى ClientHello2 مطابقة لـClientHello1 إلا في الاستثناءات الصريحة. إذا احتوى الطلب على key_share، يستبدل العميل القائمة بمساهمة جديدة واحدة للمجموعة المحددة. يحذف early_data، وينسخ cookie الذي تلقاه، ويعيد حساب PSK binders على سجل يشمل طلب الإعادة. ولا يسمح امتداد مستقبلي بفارق إضافي إلا إذا حضر في الطلب وعرّف قاعدته.

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

يجب أن تكون المجموعة المطلوبة مدرجة في supported_groups الأصلي، وألا تكون قد حصلت بالفعل على مساهمة في key_share الأول. وينبغي رفض طلب لا ينتج تغييراً، وطلب ثانٍ في الاتصال نفسه، ومجموعة تشفير لم يعرضها العميل، وServerHello يخالف المجموعة المطلوبة.

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

message_hash يبقي العرض الأول داخل السجل

تعتمد حسابات TLS على ملخص مرتب لرسائل المصافحة. فإذا أراد الخادم إصدار cookie ثم التخلص من الحالة الخاصة بكل عميل، يصبح حفظ كل ClientHello كاملة أو حالة هاش داخلية خاصة بالمكتبة عبئاً غير مرغوب.

لذلك يستبدل TLS رسالة ClientHello1 برسالة تركيبية نوعها 254 واسمها message_hash، وجسمها Hash(ClientHello1). ثم يتابع السجل بـHelloRetryRequest وClientHello2 وServerHello ورسائل التوثيق. تظل CertificateVerify وFinished وPSK binder اللاحق مرتبطة بالعرض الأول.

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

الدعم والتوقع والاختيار حالات مختلفة

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

تجعل المجموعات الهجينة لما بعد الحوسبة الكمية هذه المقايضة أوضح. يتيح OpenSSL تعريف مجموعات متقاربة ومساهمات متوقعة وتفضيل الخادم. وتحذر وثائقه من أن ClientHello كبيرة قد تعبر حد مقطع TCP وتصطدم بجدار ناري معيب، بينما يؤجل حجب المساهمة الكبيرة الكلفة إلى الخوادم التي تطلبها فعلاً. ويفصل GnuTLS بدوره بين سياسة المجموعات وخيار إرسال مساهمة TLS 1.3 واحدة.

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

لا تعبر early data طريق الإعادة

إذا احتوت ClientHello1 على early_data وجب حذفها من ClientHello2. ومن ثم يثبت HelloRetryRequest أن مسار 0-RTT لم يُقبل في تلك المصافحة.

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

ينبغي فصل محاولة early data، ورفضها بسبب HRR، وقرار إعادة الإرسال، والنتيجة التجارية. عبارة «استؤنفت الجلسة بنجاح» تمحو أهم انتقال في الحالة.

لا يثبت cookie إلا ما صُمم لإثباته

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

يضيف DTLS 1.3 استعمالاً آخر: ربط cookie بالعنوان الظاهر للعميل للتحقق من مسار العودة قبل تضخيم الرد. وتبين مناقشة تدوير الأسرار ونوافذ القبول المتداخلة والطوابع الزمنية أن الرمز عديم الحالة له دورة حياة أيضاً.

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

كل امتداد ينضم إلى التاريخ نفسه

يقدم Encrypted Client Hello مثالاً محدوداً. فقيمة random في HelloRetryRequest ثابتة، ولهذا لا يستطيع ECH وضع تأكيد القبول فيها كما يفعل في ServerHello العادية. بدلاً من ذلك يعرّف امتداد encrypted_client_hello ويشتق تأكيده من ClientHello الداخلية وسجل الطلب المعدل.

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

دليل يبقى صالحاً بعد الحادث

يبدأ السجل القابل للدفاع قبل اللحظة التي تسميها لوحات كثيرة «الاتصال». يحفظ هاش ClientHello1 وحقولها المحللة حيث تسمح السياسة، وHelloRetryRequest كما أُرسل، وهاش cookie لا سره، وحقول ClientHello2، وServerHello النهائية. ويربط كل قرار بإصدار التنفيذ والإعداد.

بالنسبة للمجموعات، تُسجل القائمة المفعلة، والترتيب المعلن، والمساهمات المتوقعة، وتفضيل الخادم، والمجموعة المطلوبة والمعادة والمتفق عليها. وبالنسبة للطلب، يُسجل السبب، والتزام الفارق بقائمة السماح، وتنبيه الرفض، وأي طلب ثانٍ. وبالنسبة للأثر، يُقاس RTT الإضافي، وحجم التحيتين، والتجزئة، ونتيجة early data، والإكمال، وفئة العميل.

ويلزم أيضاً دليل سلبي: اختبار رفض مجموعة غير معلنة، أو مجموعة أُرسلت مساهمتها مسبقاً، أو طلب بلا تغيير، أو تبديل مجموعة التشفير، أو HRR ثانٍ، أو ServerHello متناقضة. يغطي مشغل اختبارات BoringSSL أشكالاً غير صالحة لأن الرفض الصحيح جزء من قابلية التشغيل البيني.

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

المصادر