tls-auth مقابل tls-crypt: ماذا يحمي كل منهما في OpenVPN

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

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

ما الذي يحميه المفتاح المشترك فعلًا

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

tls-auth يستخدم هذا السر لحساب HMAC على حزم التحكم. وتُهمَل أي حزمة بلا توقيع صالح قبل أن تصل إلى معالجة TLS الأكثر كلفة، ولهذا يُوصف الخيار غالبًا بأنه مرشّح أول بدلًا من بديل عن TLS.

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

لا يمنح أي من الآليتين هويات. المفتاح المشترك سر جماعي، وكل من يحمله يستطيع تجاوز تلك الطبقة من الفحص.

أين يختلف الخياران

الفرق الملحوظ هو ما يراه المراقب. فمع tls-auth تكون المصافحة مرئية لكن غير قابلة للتحقق بدون المفتاح. ومع tls-crypt تكون المصافحة معتمة أمام كل من لا يحمل المفتاح.

الإعداد يختلف أيضًا. يُستخدم tls-auth مع قيمة اتجاه، فيستخدم أحد الطرفين نصف مادة المفتاح ويستخدم الآخر النصف الثاني. أما tls-crypt فيستخدم مفتاحًا واحدًا في الاتجاهين، لذا ليس توجيه الاتجاه جزءًا من ترتيبه.

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

هناك نسخة أحدث، tls-crypt-v2، تربط كل عميل بمفتاحه المغلف الخاص بحيث لا يتطلب سحب عميل واحد إعادة إصدار مفتاح المجموعة. ومن المفيد معرفتها، لكنها خيار مختلف وليست مرادفًا لأي من الخيارين هنا.

لماذا يبدو عدم التطابق وكأن شيئًا لم يحدث

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

يعيد العميل المحاولة، ولا يقول الخادم شيئًا، وتبدو الأعراض كمشكلة شبكة. فيعيد الناس تشغيل الخدمة، أو يعيدون كتابة كلمة مرور الحساب، أو يزيلون توجيه الحماية «للاختبار»، وهذا يغيّر النشر بدلًا من تشخيصه.

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

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

ما الذي يجب إعداده بشكل منفصل

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

كما أنها لا تختار شيفرة البيانات. فتلك مفاوضة منفصلة تحكمها إعدادات قناة البيانات على الطرفين، ونفق محمي بـ tls-crypt يمكن أن يستخدم مع ذلك شيفرة لم تقصدها.

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