OpenVPN: EC مقابل ED — لماذا ليست هذه الأسماء سلّم قوة
EC و ED و ECDHE و auth تجيب عن أسئلة مختلفة. رتّب ملف تعريف OpenVPN حسب الوظيفة التي يؤديها كل اسم قبل أن تقارن أو تعدّل أي شيء.
ضع ec و ed و ecdh و ecdsa و auth، إلى جانب قائمة شفرات TLS، جنبًا إلى جنب في ملف تعريف واحد، فيبدأ الملف في الظهور كقرص قوة له ستة أوضاع. لكنه ليس كذلك. كل اسم يجيب عن سؤال مختلف، وملفان يختلفان في أحد هذه الأسماء ليسا بالضرورة أقوى أو أضعف من بعضهما. وترتيب الأسماء حسب الوظيفة التي تؤديها يستغرق نحو خمس دقائق ويمنع معظم التعديلات الخاطئة التي يجريها الناس على إعداد يعمل.
يبدأ الترتيب التالي من الالتباس نفسه، ثم يتوسع نحو الأجزاء من ملف التعريف التي تحدد فعليًا ما يحمي حركة المرور لديك. ويأخذ كل قسم قراءة خاطئة واحدة بالترتيب ويعرض ما يرتبط به الاسم حقًا.
حرفان، سؤالان مختلفان
الزوج الذي يثير أكبر جدل هو EC و ED، والجدل يفترض عادة أنهما إجابتان متنافستان عن سؤال واحد. بل إنهما ليسا على المحور نفسه. يصف EC عائلة من الرياضيات: التشفير بالمنحنيات الإهليلجية، حيث تأتي الأمانة من صعوبة اللوغاريتم المنفصل على منحنى بدلًا من حقل منتهٍ كبير.
يصف ED شكل منحنى داخل تلك العائلة. ومنحنيات Twisted Edwards تمثيل مختار للسرعة وللمقاومة أمام عدة أخطاء في التنفيذ، وEd25519 هو الاسم الذي يعنيه الناس عادة. وليس المنحنى منافسًا للتشفير بالمنحنيات الإهليلجية؛ بل هو طريقة واحدة لكتابة منحنى إهليلجي. وقراءة ED بوصفه «الـ EC الأحدث والأقوى» هي أول منعطف خاطئ، وكل ما بعدها يميل إلى الخطأ في الاتجاه نفسه.
التوقيع والتبادل وظيفتان منفصلتان
بعد حسم مسألة العائلة، تنقسم الأسماء المتبقية إلى عمودين لا يحل أحدهما محل الآخر أبدًا. أحد العمودين يوقّع، والآخر يتفق على سر مشترك.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
يوقّع كل من EdDSA و ECDSA، لكنهما مخططان مختلفان بصيغ مفاتيح مختلفة، لذا فإن الشهادة الصادرة لأحدهما لا تصلح للآخر. وEdDSA معرّف لمجموعة صغيرة من المنحنيات؛ وP-256 ليس واحدًا منها، ولهذا تتحقق شهادة P-256 بـ ECDSA ولا تتحقق أبدًا بـ Ed25519.
لا يوجد في عمود التبادل ما يعادل EdDH. والاتفاق العابر على مفتاح Curve25519 هو X25519، وهو ECDH بمنحنى معين، تمامًا كما هو الحال مع P-256. وEd25519 يعني بدقة مخطط التوقيع، وإن كان الاسم يُستخدم بتراخٍ للتبادل لأن المنحنيين مرتبطان: فصيغة Edwards المستخدمة للتوقيع وصيغة Montgomery المستخدمة في X25519 تصفان الزمرة الأساس نفسها.
لماذا لا يحتوي ملف تعريف EC على ملف dh
يحتوي ملف dh على معاملات مولدة مسبقًا لتبادل Diffie-Hellman في الحقول المنتهية، وهذه المعاملات موجودة لأن العدد الأولي الكبير والمولّد يجب أن يأتيا من مكان ما. ولا يحتاج تبادل المنحنيات الإهليلجية إليها: فالمنحنى المسمى هو مجموعة المعاملات، والطرفان يعرفانها بالفعل. وهذا هو السبب الكامل الذي يسمح لملف تعريف EC بحذف التوجيه.
لا تزال حالتان تنتجان سطر dh في ملف تعريف يبدو حديثًا في ما عدا ذلك. الأولى مستمع ثانٍ أو نظير أقدم يتفاوض فعليًا على زمر في حقل منتهٍ. والثانية نص متبقٍ نُسخ من قالب من عصر RSA ولم يُحذف أبدًا. وملف تعريف يسمي منحنى للتبادل ولا يزال يحمّل ملف dh بطول 2048 بت ليس أكثر أمانًا لأنه فعل ذلك؛ بل هو يحمل قطعة أثرية غير مستخدمة.
TLS 1.3 حذف تبادل المفاتيح من الاسم
قارن TLS_AES_256_GCM_SHA384 بـ TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 فيبدو الاسم الأقصر كأنه تخفيض. لكنه إعادة تسمية، والسبب بنيوي: فقد أزال TLS 1.3 تبادل المفاتيح الثابت بـ RSA وتبادل Diffie-Hellman في الحقول المنتهية، فلم يبق خيار غير PSK سوى تبادل عابر بالمنحنيات الإهليلجية. وتسميته في كل حزمة كانت ستكرر الحقيقة نفسها اثنتي عشرة مرة.
اختفى نوع الشهادة من الاسم لسبب ذي صلة. ففي 1.3 تصادق الشهادة على توقيع المصافحة، لا على اتفاق المفاتيح، فلم تعد تختار الحزمة. ولهذا أيضًا توجد قائمة شفرات منفصلة لـ 1.3 في الإعداد: فقد أُعيدت تسمية الحزم وأُعيد تنظيمها، لا أُضعفت.
هناك نتيجة واحدة تستحق الذكر بوضوح. ECDHE خوارزمية تبادل مفاتيح وليست شفرة تشفير أبدًا. والحزمة الموصوفة بأنها «إهليلجية» تقول شيئًا عن كيفية وصول الطرفين إلى مفتاح مشترك، ولا تقول شيئًا عن الذي يشفّر الحمولة بعد ذلك.
auth يصادق على الحزم، لا على الحمولات
يختار التوجيه auth ملخص HMAC الذي يصادق على الحزم، وقيمته الافتراضية التاريخية هي SHA1. ومع شفرة بيانات غير AEAD، يحسب OpenVPN الملخص على النص المشفَّر ويضيفه إليه، وهو ترتيب تشفير-ثم-MAC هو ما يجعل التلاعب بالحشو غير عملي.
الأسطورة هنا أن رفع auth إلى SHA512 يقوّي النفق. وهو لا يرفع قوة التشفير، وإذا كانت شفرة البيانات المتفاوض عليها وضع AEAD مثل AES-256-GCM، فإن الملخص لا يُطبَّق على حزم البيانات إطلاقًا. فوسم GCM يصادق عليها بالفعل، وتُترك قيمة auth لـ HMAC قناة التحكم ولأي شفرة غير AEAD لا تزال قيد الاستخدام.
إذن التوجيه مهم، لكنه مهم في موضع أضيق مما يوحي به موقعه في الملف. ومعرفة الشفرة التي جرى التفاوض عليها فعلًا تخبرك ما إذا كان ينطبق أصلًا.
اقرأ ملف التعريف بالعمود، لا بالرتبة
تفصل ثلاثة أسئلة الطبقات بعضها عن بعض، ويجيب عن كل منها جزء مختلف من الجلسة المتفاوض عليها. أي شفرة تحمي الحمولة؟ وأي وسم أو ملخص يضمن كل حزمة، وهل تحتاج الشفرة المستخدمة إليه أصلًا؟ وشهادة من أغلقت المصافحة، وهل قناة التحكم محمية إضافةً بـ tls-auth أو tls-crypt؟
لا شيء في وسم EC أو ED يحسم أيًا من تلك الثلاثة، واسم الحزمة وحده لا يحسم أيًا منها أيضًا. والنتيجة المتفاوض عليها هي الدليل الوحيد، فاقرأها بدلًا من استنتاج القوة من المفردات:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logيخبرك الأمر الأول بمخطط التوقيع الذي تستخدمه شهادتك فعلًا، وهو الطريقة الموثوقة الوحيدة لمعرفة ما إذا كنت تشغّل ECDSA أو Ed25519. ويعرض الثاني سطر قناة التحكم الذي سجّله العميل للجلسة، بما في ذلك إصدار TLS والحزمة التي استقر عليها. وإذا لم يكن تعديل ملف التعريف مبررًا بأحد هذين المخرجين، فهو على الأرجح تغيير في اسم لا في خاصية.