هل فشل مصافحة VPN يعني حقًا هجوم خفض التشفير؟

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

ما الذي يغيّره هجوم خفض التشفير فعليًا

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

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

لماذا يجب مصادقة التفاوض نفسه

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

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

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

التوافق المُعدّ مسبقًا ليس هجومًا

يمكن للمسؤول أن يسمح عمدًا بخيارات أقدم لدعم عميل موثّق، وهذا القرار ظاهر في الإعدادات. لا يستطيع المهاجم إنشاء ذلك الإعداد؛ بل يمكنه فقط استغلال مسار يسمح له بالتأثير على العرض.

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

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

اقرأ الفشل قبل أن تسمّي سببًا

احتفظ بنص الخطأ الدقيق، وإصداري العميل والخادم، والوقت قبل أي تغيير. ثم صنّف: هل اختلف النظيران حول عرض، أم فشل مسار الحزم، أم رفض أحد الطرفين معاملًا كان قد قبله؟

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

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

تأكد مما تم اختياره فعليًا

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

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

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