الخلاصة

  • تجعل RFC 8446 الصادرة في أغسطس 2018 الامتداد supported_versions موضع تفاوض نسخة TLS 1.3 الفعلية. وتبقي حقول legacy_version القيمة 0x0303 التي تعني TLS 1.2؛ قراءة تلك الحقول وحدها تعطي وصفاً خاطئاً للاتصال.
  • إذا تفاوض خادم قادر على TLS 1.3 على TLS 1.2، وجب أن ينهي ServerHello.random بالبايتات 44 4F 57 4E 47 52 44 01. ولـTLS 1.1 أو أدنى يصبح البايت الأخير 00. على عميل TLS 1.3 إيقاف المصافحة إذا رأى أياً من العلامتين في رد يعلن نسخة قديمة.
  • عالجت RFC 7507 في 2015 مساراً آخر: يضع العميل TLS_FALLBACK_SCSV حين يعيد المحاولة بنسخة أدنى، ويستطيع خادم يدعم نسخة أعلى الرد بتنبيه inappropriate_fallback. تسجل IANA القيمة والتنبيه.

رقم قديم عند البوابة

قد يصنف مراقب يقرأ ServerHello.legacy_version وحده اتصال TLS 1.3 على أنه TLS 1.2. تبقي RFC 8446 فيه 0x0303 وتنقل القرار الحقيقي إلى supported_versions. كلمة «legacy» تحدد وظيفة الحقل: إبقاء هيئة الرسالة الموروثة، لا الإبلاغ عما تنفذه الأجهزة الطرفية من حماية. إذا ساوى نظام المراقبة بين شارة البوابة وحالة الاتصال، يبدأ سجل الأمن بخطأ.

جاءت الحاجة إلى الشارة من الطريق بين الطرفين. اعتادت بعض الأجهزة الوسيطة شكلاً معيناً للمصافحة القديمة، وفشلت حين رأت نمطاً جديداً. يصف الملحق D.4 في RFC 8446 وضع توافق يجعل TLS 1.3 يبدو شبيهاً بـTLS 1.2: يرسل العميل معرّف جلسة غير فارغ، وقد تظهر رسائل ChangeCipherSpec شكلية. عندما يختار الطرفان TLS 1.3 في الامتداد، يكون البروتوكول المنفذ TLS 1.3. اللباس القديم موجه إلى الحارس في منتصف الطريق.

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

علامة في نهاية العدد العشوائي

وراء التوافق الشكلي خطر أشد: يستطيع مهاجم في الطريق محاولة دفع الطرفين إلى نسخة أقدم. يفرض RFC 8446 على الخادم القادر على TLS 1.3 إذا تفاوض على TLS 1.2 أن يكتب في آخر ثمانية بايتات من ServerHello.random التسلسل 44 4F 57 4E 47 52 44 01. وإذا اختار TLS 1.1 أو أدنى، حافظ على السبعة الأولى وجعل الأخيرة 00. تقرأ السبعة الأولى DOWNGRD بترميز ASCII، ويميز البايت الأخير مجال النسخة الأدنى.

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

تحدد RFC نطاق هذا الإنذار بدقة. هو حماية إضافية محدودة فوق تبادل Finished. في مجموعات التشفير ذات المفاتيح المؤقتة، يربط توقيع المصافحة القديمة القيم العشوائية؛ أما RSA الثابت فلا يمنح الحماية نفسها. ويسجل النص أن كثيراً من تطبيقات TLS 1.2 الموجودة بالفعل لن تتبع القاعدة الجديدة. لا تعمل البايتات الثمانية إلا حيث يكتبها خادم قادر ويفحصها عميل قادر.

إشارة أخرى جاءت من إعادة محاولة العميل

تناولت RFC 7507 عام 2015 حركة مختلفة. بعض العملاء، بعد فشل مصافحة، يعيدون المحاولة بنسخة أدنى سعياً إلى التوافق. يمكن لمهاجم يسبب الفشل دفعهم إلى ذلك. يحمل العميل عند الإعادة TLS_FALLBACK_SCSV؛ فإذا كان الخادم يدعم نسخة أعلى، يجيب بـinappropriate_fallback. يحتفظ سجل معلمات TLS لدى IANA بالقيمة والتنبيه.

إشارة 2015 يرسلها العميل وهو يعيد المحاولة. علامة 2018 يضعها الخادم القادر على TLS 1.3 في قيمته العشوائية. تكشف كل منهما معرفة طرف مختلف في وقت مختلف من التفاوض. دمجهما في عبارة عامة عن منع التراجع يخفي السؤال الحاسم: من كان يعرف أن نسخة أفضل متاحة حين عاد الاتصال إلى الوراء؟

لمن كانت البدلة القديمة؟

يسجل الملحق D.4 ضغط الأجهزة المنشورة على شكل معيار جديد. احتاج TLS 1.3 إلى ملامح مألوفة كي يجتازها. أما العلامة في ServerHello.random فرسمت حداً آخر: التنازل في المظهر لا يمنح الأجهزة الوسيطة حق فرض نسخة أضعف بصمت. احتفظ الطرفان بقرار النسخة، وحصل العميل على أثر يمكن فحصه حين يختار خادم قادر نسخة أدنى.

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