AnyConnect وإصدار TLS غير المسموح على Linux: حدّد نطاق الإصلاح أولاً

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

اقرأ الرسالة قبل أن تلمس النهج

احتفظ بالنص الحرفي من مربع الحوار. شكوى الإصدار تشير إلى طبقة البروتوكول، وشكوى الشهادة تشير إلى الثقة أو التسمية، وفشل تسجيل الدخول يشير إلى بيانات الاعتماد. بوابة تقدّم TLS 1.0 مع مجموعة DHE بـ 1024 بت وAES-256-CBC وتوقيع SHA-1 قد تحمل شهادة صالحة تماماً ومع ذلك يرفضها نهج حديث قبل أن تُرسَل بيانات اعتمادك أصلاً.

افحص النقطة الطرفية باستخدام OpenSSL الخاص بالنظام، مع اسم المضيف الحقيقي والمنفذ الذي يستخدمه العميل.

فشل openssl s_client -connect vpn.example.com:443 -servername vpn.example.com مع نجاح -tls1 -cipher DEFAULT@SECLEVEL=0 يخبرك أن الحدّ هو الإصدار وحجم المفتاح معاً. إذا أبلغ الأمر الأول عن مفتاح DH صغير بدل تنبيه بروتوكول، فالإصدار سليم والمجموعة وحدها تحتاج إلى انتباه. لا تضع أبداً مفتاحاً خاصاً أو كلمة مرور في الفحص.

الخيار 1: تخفيف المضيف بأكمله عبر نهج التشفير

على Fedora وRHEL 8 و9، يخفض update-crypto-policies --set LEGACY نهج OpenSSL النظامي، ويؤكد update-crypto-policies --show ما هو نشط. عادةً ما يستعيد ذلك النفق، لكن النهج يُقرأ عند بدء العملية، لذا أعد تشغيل العميل وأي مساعد أنشأه قبل إعادة الاختبار. كما يسمح ببروتوكولات أقدم ومجموعات أضعف لكل عميل TLS على الجهاز، من المتصفح في النافذة المجاورة إلى مدير الحزم الذي يحدّث النواة.

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

لا يملك Debian وUbuntu مفتاحاً واحداً لهذا. المكافئ هو تعديل /etc/ssl/openssl.cnf يضبط MinProtocol أدنى وCipherString = DEFAULT@SECLEVEL=0 في قسم إعدادات النظام الافتراضية. النطاق نفسه، وملف مختلف، وأسهل قليلاً في أن يضيع أثناء ترقية إصدار.

الخيار 2: ملف إعداد واحد لعميل واحد

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

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

وجّه OPENSSL_CONF إلى ذلك الملف وأطلق عميل VPN عبر غلاف يصدّره. كل شيء آخر على المضيف يحتفظ بالنهج الافتراضي، وهذه هي الخصيصة المهمة عندما يأتي سؤال الامتثال. تأكد من أن الملف ساري فعلاً قبل لوم البوابة: يجب أن يسرد OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 شيفرات TLS 1.0، والنتيجة الفارغة تعني أن السلسلة مكسورة وأن العميل أبقى بصمت على إعدادات النظام الافتراضية.

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

الحد هو التغطية. أي شيء مرتبط بـ GnuTLS أو NSS يتجاهل OPENSSL_CONF، وكذلك أي عملية مساعدة ينشئها العميل دون أن يرث البيئة. تحقق بـ ldd من مكتبة TLS التي يرتبط بها الملف التنفيذي فعلاً قبل بناء الغلاف، لأن الجواب يحدد ما إذا كان هذا الخيار موجوداً أصلاً.

الخيار 3: جهاز ظاهري أو حاوية قابلة للتخلص

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

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

ما تتركك به المقارنة

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

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