الخلاصة

  • سمح TLS 1.2 بمصافحة جديدة داخل اتصال قائم من دون إثبات المصافحة السابقة التي تواصلها.
  • حفظ RFC 5746 قيم verify_data من المصافحة السابقة، وفرض التحقق منها أثناء إعادة التفاوض.

مصافحتان صحيحتان ومحادثة زائفة

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

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

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

جعل Finished السابقة جزءاً من حالة الاتصال

أضاف RFC 5746 علماً باسم secure_renegotiation، وحفظ لكل اتصال قيمتي verify_data للعميل والخادم من المصافحة السابقة مباشرة. كانت القيم تخص الاتصال الحي، لا مجرد إدخال في ذاكرة جلسات قابلة للاستئناف.

حملت إضافة renegotiation_info، ذات النوع 0xff01، هذا التاريخ إلى التفاوض التالي. في المصافحة الأولية يكون حقل renegotiated_connection فارغاً. وفي إعادة التفاوض يرسل العميل قيمة client_verify_data المحفوظة؛ يقارنها الخادم بحالته ثم يعيد ضم قيمة العميل إلى قيمة الخادم. ويتحقق العميل من النتيجة. يؤدي غياب الإضافة المطلوبة أو اختلاف القيمة إلى إجهاض المصافحة بخطأ قاتل.

وهنا تكمن القراءة التفسيرية: لم يعد إكمال المصافحة كافياً؛ بل يجب أن تكون المصافحة التالية الصحيحة لهذا الاتصال بعينه.

إشارة توافق لم تكن مجموعة تشفير

كانت بعض التطبيقات القديمة تفشل عند استقبال إضافات مجهولة. لذلك عرّف RFC 5746 الإشارة TLS_EMPTY_RENEGOTIATION_INFO_SCSV، بالترميز 0x00,0xFF، داخل قائمة مجموعات التشفير. وكان من المفترض أن تتجاهل التطبيقات القديمة المجموعات المجهولة، فتمكن العميل من إعلان القدرة من دون الاعتماد على محلل إضافات سليم.

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

من الإصلاح إلى الإزالة

اختار TLS 1.3 حداً معمارياً مختلفاً: إعادة التفاوض ممنوعة. ويجب التعامل مع ClientHello يصل لاحقاً على اتصال TLS 1.3 كرسالة غير متوقعة. وإذا تلقى اتصال أُنشئ بإصدار أقدم رسالة ClientHello لـ TLS 1.3 أثناء إعادة التفاوض، فعليه الاحتفاظ بإصداره السابق ولا يمكنه الترقية بهذه الطريقة إلى TLS 1.3. أما KeyUpdate والمصادقة بعد المصافحة فآليتان مختلفتان، ولا ينبغي تسميتهما إعادة تفاوض.

بالنسبة إلى TLS 1.2، يفرض RFC 9325 على العميل والخادم تنفيذ renegotiation_info، وعلى العميل إنهاء الاتصال إذا لم يقر الخادم بالإضافة. لم يحل RFC 5746 كل مشكلة تتعلق بالمصافحات المتعددة؛ إذ يتناول RFC 9325 بشكل منفصل السر الرئيسي الممتد وخطر triple handshake. لكن إنجازه التاريخي محدد: أصبحت الاستمرارية الزمنية خاصية موثقة، لا افتراضاً تتركه الطبقة للتطبيق.

المصادر