هل يمكن لشهادة RSA أن تعمل مع dh none في OpenVPN؟

هذه إعدادات خادم تقول dh none إلى جانب شهادة تقول RSA، مع شكّ ملحّ بأن أحدهما لا بد أن يكون خطأ. لا شيء خطأ. الشهادة توقّع وتصادق؛ وتبادل المفاتيح ينشئ سرًّا مشتركًا. هاتان مهمتان مختلفتان في المصافحة نفسها، وTLS يسمح لشهادة RSA بأن تصادق على مصافحة تستخدم اتفاقًا مؤقتًا على المنحنى الإهليلجي.

يأتي الالتباس عادةً مع دليل ترحيل. يقول باستبدال ملف معاملات DH بـ dh none، فيلاحظ القارئ أن الشهادة ليست شهادة منحنى إهليلجي، فتُعامَل الحقيقتان على أنهما تناقض.

لماذا يبدو الإعدادان مرتبطين

الإعدادات الأقدم في OpenVPN كانت تطلب ملف معاملات DH لأن Diffie-Hellman في الحقل المحدود يحتاج معاملات نطاق يتفق عليها الطرفان. كانت توجيهات dh تشير إلى ذلك الملف. وعندما ينتقل النشر إلى ECDH، تأتي المعاملات من منحنى مسمّى بدلًا من ذلك، فلا يعود الملف مطلوبًا، وهذا ما يعبّر عنه dh none.

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

التسمية تزيد التداخل سوءًا. يظهر «المنحنى الإهليلجي» في اسمي مجموعة ECDHE وECDSA، فيسهل افتراض أن أي اتصال يذكر منحنى لا بد أن يتضمن شهادة منحنى. ليس الأمر كذلك.

قراءة اسم مجموعة TLS 1.2 قراءةً صحيحة

خُذ ECDHE-RSA-AES256-GCM-SHA384. الرمز الأول هو عائلة تبادل المفاتيح: Diffie-Hellman المؤقت على المنحنى الإهليلجي. والثاني هو عائلة المصادقة: RSA. أما الباقي فيصف حماية السجلات والتجزئة المستخدمة في المصافحة.

مجموعة ECDHE-ECDSA تستخدم عائلة تبادل المفاتيح نفسها مع طريقة مصادقة مختلفة، لذا تحتاج شهادة منحنى إهليلجي. ومجموعة DHE-RSA تستخدم Diffie-Hellman المؤقت في الحقل المحدود مع مصادقة RSA، وتلك تحتاج فعلًا إلى معاملات DH.

اقرأ اسم المجموعة من اليسار إلى اليمين وأسند كل جزء إلى مهمته. وبعد فصل الرموز، يتحول السؤال من «هل تطابق شهادتي dh none» إلى «هل يسمح خادمي بمجموعة لا يحتاج تبادل مفاتيحها إلى ملف DH».

ما يعطّله dh none فعليًا

dh none يطلب من الخادم ألّا يحمّل ملف معاملات DH في الحقل المحدود. وهو لا يعطّل المصادقة ولا التحقق من الشهادات ولا TLS نفسه. لكنه يشترط أن يكون تبادل المفاتيح المتفق عليه واحدًا لا يحتاج تلك المعاملات، وهو عمليًا مجموعة ECDHE أو مصافحة TLS 1.3.

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

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

dh none ليس تخفيضًا أمنيًّا بحد ذاته. فقوة التبادل تعتمد حينها على المنحنى والمجموعة المتفاوض عليهما فعليًا، ولهذا فإن الخطوة التالية هي النظر في ما اختاره الطرفان لا في الملف الغائب.

تأكيد التفاوض قبل التعديل

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

إذا أظهر TLS 1.2 مع مجموعة ECDHE-RSA وشهادة RSA، فالمزيج هو بالضبط ما يتوقعه dh none، ولا شيء يحتاج إلى إصلاح. وإذا أظهر مجموعة DHE أو فشل مصافحة دون شفرة مشتركة، فالعلاج في سياسة الشفرات أو في قدرة العميل، لا في الشهادة.

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

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

قائمة التحقق: هل الشهادة RSA، وهل مجموعة ECDHE مسموح بها، وهل يُظهر السجل تلك المجموعة، وهل يتفاوض عليها أقدم عميل مدعوم أيضًا؟ إذا كانت الإجابات الأربع بنعم، فإن dh none يؤدي وظيفته.