كيف يمكن تعطيل إصدارات TLS القديمة ضمن إعدادات الامتثال لـ HTTPS؟

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

قبل البدء، تحقّق من نقطة إنهاء اتصال TLS في المتصفح. إذا كان الموقع يستخدم CDN أو WAF أو موازن تحميل، فقد يظل مدخل الإنترنت العام يقبل البروتوكولات القديمة حتى بعد تعديل إعدادات الخادم الأصلي وحده.

حدّد جميع نقاط دخول HTTPS التي تحتاج إلى تعديل

غالبًا ما تستخدم المواقع الرسمية للشركات المصدّرة، والمتاجر العابرة للحدود، وصفحات الهبوط الإعلانية مسار وصول من الشكل «الزائر—CDN/WAF—موازن التحميل—الخادم الأصلي». ولكل اتصال TLS مستقل يُنشأ على امتداد هذا المسار إعداداته الخاصة للبروتوكول. أما إذا كان الجهاز الوسيط يمرّر حركة المرور فقط، فيتحكم في الإعداد المكوّن الذي ينهي TLS فعليًا في الخلفية.

يُنصح بحصر النقاط حسب اسم النطاق ومنفذ الاستماع، بدلًا من فحص عدد الخوادم فقط:

• مداخل الإنترنت العامة: النطاق الرئيسي، والنطاق الفرعي www، والمواقع متعددة اللغات، والمتجر، وواجهات API، وصفحات الهبوط الإعلانية.
• مسارات الاتصال بالخادم الأصلي: اتصالات HTTPS من CDN إلى موازن التحميل، ومن الوكيل العكسي إلى خدمة التطبيق.
• مداخل بديلة: عناوين الخادم الأصلي التي يمكن الاتصال بها مباشرة، والنطاقات الاحتياطية، ومداخل الإدارة، ومنافذ HTTPS الأخرى.

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

حدّد البروتوكولات المسموح بها بوضوح عند الإعداد

بدلًا من استبعاد الإصدارات القديمة واحدًا تلو الآخر، يكون من الأوضح تحديد البروتوكولات المسموح بها صراحةً. قبل الإعداد، تحقّق من أن خدمة الويب ومكتبة TLS المرتبطة بها تدعمان الإصدارات المطلوبة؛ فإضافة TLS 1.3 إلى ملف الإعدادات لا تعني أن البيئة الحالية قادرة على توفيره.

مثال على إعداد Nginx

أضف الإعداد التالي ضمن سياق الإعداد المناسب:

ssl_protocols TLSv1.2 TLSv1.3;

إذا كانت جميع المواقع تتبع السياسة نفسها، فيمكن إدارة الإعدادات على مستوى http، مع التحقق من عدم وجود إعدادات متجاوزة في أي من أقسام server. وعند استضافة عدة مضيفين افتراضيين لـ HTTPS على العنوان والمنفذ نفسيهما، تحقّق أيضًا من إعدادات المضيف الافتراضي. فقد يتأثر تفاوض البروتوكول بإعدادات الخادم الافتراضي، لذا لا تقتصر على تعديل كتلة الإعداد الخاصة بالنطاق المستهدف.

بعد الحفظ، افحص الصياغة أولًا ثم أعد تحميل الخدمة:

nginx -t
nginx -s reload

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

التعامل مع Apache والمنصات المُدارة

يمكن تقييد البروتوكولات في Apache باستخدام التوجيه SSLProtocol، مثل الإعداد التالي في البيئات التي تدعم الإصدارات المعنية:

SSLProtocol -all +TLSv1.2 +TLSv1.3

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

في حالات استخدام منصات متكاملة لإنشاء المواقع وتقديم خدمات التسويق، مثل 易营宝، قد تتولى أدوار مختلفة صيانة صفحات الموقع ونطاقات التسويق وCDN والخادم الأصلي. قبل التنفيذ، حدّد المسؤولية عن إعداد كل مدخل وطريقة التحقق منه؛ فلا ينبغي اعتبار أن «المنصة أصدرت شهادة» دليلًا على تعطيل البروتوكولات القديمة في جميع المداخل.

يجب أن يثبت التحقق رفض الإصدارات القديمة وإتاحة الإصدارات الحديثة

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

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

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

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

افحص النطاق العام والخادم الأصلي كلًا على حدة. وللاتصال بالخادم الأصلي مباشرةً، يمكن تغيير -connect إلى عنوان IP الخاص به مع الاستمرار في تحديد النطاق باستخدام -servername. واختبر أيضًا IPv4 وIPv6 والمداخل الاحتياطية وعُقد النشر المختلفة. احتفظ بوقت الفحص والعنوان المستهدف ونتائج التفاوض لتسهيل القبول الفني واستكشاف المشكلات لاحقًا.

تحقّق من التوافق عبر مسارات العمل الفعلية

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

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

لا يشكّل تعطيل TLS القديم سوى جزء من أعمال HTTPS. ففي TLS 1.2، لا يزال يتعين مراجعة مجموعات التشفير، كما يجب التعامل بصورة منفصلة مع سلسلة الشهادات ومطابقة أسماء النطاقات وإدارة تواريخ الانتهاء والمحتوى المختلط. ولكل من إعادة التوجيه من HTTP وHSTS دور مختلف، ولا يحل أي منهما محل تقييد البروتوكولات. عند التسليم، احتفظ بقائمة المداخل والإعدادات السارية وسجلات التحقق، وافحص أي نطاق تسويقي جديد أو عملية نقل لـ CDN وفق خط الأساس نفسه.