الخلاصة

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

الخلل كان في حدود الاتصال

في TLS 1.2، كان من الممكن إجراء مصافحة جديدة على اتصال قائم. يوضح RFC 5246 تصميم TLS 1.2 وإمكان إعادة التفاوض، بينما وثّق RFC 5746 المشكلة التي ظهرت عندما لم تكن المصافحة الجديدة مرتبطة تشفيرياً بالمصافحة السابقة.

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

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

إصلاحان مختلفان في RFC 5746

لم يكن الإصلاح مجرد إعلان بأن الطرف يدعم إعادة التفاوض الآمن. أضاف RFC 5746 امتداد renegotiation_info، الذي يحمل بيانات تحقق تربط المصافحة الجديدة بالمصافحة السابقة. كما أضاف TLS_EMPTY_RENEGOTIATION_INFO_SCSV، وهي إشارة يستطيع العميل استخدامها أثناء المصافحة الأولية للإعلان عن دعم إعادة التفاوض الآمن.

التمييز بين الآليتين مهم. الإشارة الأولية تقول إن الطرف يدعم آلية الحماية؛ أما بيانات التحقق من المصافحة السابقة فتؤدي وظيفة الربط التشفيري عند إعادة التفاوض. ويمنح هذا الربط التنفيذ المحدّث طريقة للتمييز بين إعادة تفاوض مرتبطة بأمان وسلوك قديم غير مرتبط.

من الإصلاح إلى الإرشاد ثم الإزالة

حافظت RFC 7525 على التعامل مع إعادة التفاوض الآمن ضمن إرشادات الاستخدام التشغيلي لإصدارات TLS الأقدم. وفي RFC 8446، أزال TLS 1.3 إعادة التفاوض بدلاً من نقل الوظيفة العامة إلى الإصدار الجديد. أما KeyUpdate والمصادقة اللاحقة للمصافحة فهما آليتان أضيق نطاقاً، وليستا عودة لإعادة التفاوض العامة.

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

ما الذي لا تثبته وثائق المعيار؟

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

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

الفجوة ليست في كتابة معيار جديد فقط. الفجوة هي الانتقال من سلوك محدد في السلك إلى سلوك متحقق منه عبر النظام الكامل. نشر البروتوكول ليس دليلاً على النشر الشامل، ووجود دعم لـ RFC 5746 ليس دليلاً تلقائياً على أن سياسة الخدمة ترفض كل سلوك قديم حيث يجب رفضه.