Defaults.Exposed › الإصلاحات › التشفير الحديث (إصدار TLS والأصفار)

كيف تُصلح التشفير الحديث (إصدار TLS والأصفار)

TLS هو القفل الذي يشوّش البيانات المتدفّقة بين زوّارك وموقعك. أمران يجعلان ذلك القفل جديراً بالثقة: استخدام إصدار حديث من TLS (لا الإصدارات القديمة المعطوبة)، واستخدام أصفار قوية (وصفة التشويش الفعلية). تغطّي هذه الصفحة كليهما — بالإضافة إلى بضعة إعدادات ذات صلة لا تؤثر في درجتك لكنها تستحق المعرفة.

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

ماذا قد يكلّفك هذا

• يدفع عميل أو يسجّل الدخول عبر شبكة Wi-Fi فندق أو مقهى، فيتيح اتصال عتيق أو صفر ضعيف لغريب على تلك الشبكة قراءة بطاقته وكلمة مروره، فيتتبّع الاحتيال — والمكالمة الغاضبة — مباشرة إلى موقعك.
• تتقدّم لقبول مدفوعات البطاقات (أو يعيد مزوّد الدفع تدقيقك) فتُرفَض لأن TLS عتيقاً أو صفراً محظوراً يخالف قواعد أمن المدفوعات — فتُجمَّد صفحة الدفع لديك حتى يُصحَّح الأمر.
• يُجري فريق تقني لدى عميل أكبر فحصاً أمنياً روتينياً قبل التوقيع، فيرى أن موقعك لا يزال يسمح بتشفير معطوب، فيصنّفك كخطر — فيتعثّر العقد بسبب مشكلة لا يكلّف إصلاحها شيئاً.
• تصل شكوى حماية بيانات أو اختراق إلى مكتبك، وأول سؤال تطرحه الجهات التنظيمية هو ما إذا كنت قد حميت بيانات العملاء 'بشكل مناسب' — وتشغيل تشفير معروف بأنه معطوب علناً منذ سنوات جواب صعب جداً تقدّمه.
• يُظهِر موقعك قفلاً، فيفترض الجميع أنه آمن تماماً، وتمرّ هذه الثغرة دون ملاحظة لسنوات — حتى يتحوّل تسجيل دخول أو رقم بطاقة معترَض واحد إلى حادث أكثر كلفة بكثير من الإصلاح المجاني.

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

بكلمات بسيطة

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

1. إصدار TLS — أيّ جيل من التقنية تستخدمه. الإصدارات المبكرة (TLS 1.0 و1.1) كانت معطوبة علناً منذ سنوات؛ والآمنة هي TLS 1.2 وTLS 1.3.
2. الصفر — الوصفة المحددة التي يستخدمها TLS للتشويش. بعض الأصفار (مثل RC4 وDES و3DES) كُسِرت وأصبحت محظورة الآن؛ والأصفار الحديثة لا تزال قوية.

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

ما قد يكلّفك هذا

• سُرِق عميل على شبكة Wi-Fi عامة. يسجّل أحدهم الدخول إلى حسابه أو يدفع من فندق أو مقهى أو مطار. ولأن موقعك لا يزال يسمح بإصدار TLS قديم أو صفر ضعيف، يُجبِر غريب على تلك الشبكة نفسها الاتصال على النزول إلى الخيار القابل للكسر ويقرأ كلمة مروره ورقم بطاقته في الوقت الفعلي. يقع الاحتيال على العميل، لكن اللوم — ومكالمة الدعم — يقعان عليك.
• تُطفأ مدفوعات بطاقاتك. تتطلب قواعد أمن المدفوعات (PCI DSS) TLS 1.2 كحدّ أدنى وتحظر صراحةً الأصفار الضعيفة مثل RC4. وحين يعيد معالجك تدقيقك، أو حين تتقدّم لقبول البطاقات، يفشل إعداد عتيق في الفحص فتُجمَّد صفحة الدفع لديك حتى يُصحَّح — في أسوأ لحظة للتدفق النقدي.
• تتعثّر صفقة في مراجعة أمنية. قبل أن يوقّع عميل أكبر، يُجري فريقه التقني فحصاً روتينياً. فيُعلِّم فوراً أن موقعك لا يزال يقبل تشفيراً معطوباً — نوع النتيجة الذي يبدو مهملاً ويجعل المشتري يتساءل عمّا هو غير محكَم أيضاً. ويبقى العقد في طيّ النسيان بسبب مشكلة لا يكلّف إصلاحها شيئاً.
• تطرح جهة تنظيمية السؤال المحرج. بعد أي شكوى أو اختراق، أول ما تريد سلطة حماية البيانات معرفته هو ما إذا كنت قد حميت البيانات الشخصية “بشكل مناسب.” وتشغيل تشفير معروف بأنه معطوب علناً منذ سنوات صعب جداً الدفاع عنه، و”لم ندرك أن الإصدار القديم لا يزال مفعّلاً” ليس جواباً مريحاً.
• يختبئ خلف القفل لسنوات. لأن موقعك لا يزال يُظهِر قفلاً طبيعياً، لا يلاحظ أحد الثغرة — حتى يصبح تسجيل دخول أو رقم بطاقة معترَض واحد حادثاً عاماً أكثر كلفة بكثير من إصلاح الخمس دقائق.

ما هو فعلاً

إصدار TLS

الموقع لا يدعم إصداراً واحداً فقط من TLS — بل يمكنه عرض عدة إصدارات في آن واحد ويترك متصفح كل زائر يختار. سيستخدم زائر حديث أحدث إصدار متاح ويرى قفلاً طبيعياً. والخطر أن الإصدارات القديمة المعطوبة يمكن أن تجثم هناك إلى جانب الجيدة كباب خلفي مفتوح: يستطيع مهاجم إجبار اتصال زائر على “النزول” إلى TLS 1.0 أو 1.1 ثم استغلال نقاط الضعف المعروفة في تلك الإصدارات (هجوما BEAST وPOODLE هما المثالان الشهيران) لفكّ تشفير الحركة.

فيتصل فحصنا بموقعك ويختبر كل إصدار على حدة — TLS 1.0 و1.1 و1.2 و1.3 — ليرى أيّها لا يزال خادمك يقبله. إليك كيف يبدو “الجيد” وكيف يُقيَّم:

• TLS 1.3 (مع 1.2 أو بدونه)، ودون إرث قديم: أفضل نتيجة — إعداد حديث نظيف. الدرجة الكاملة.
• TLS 1.2 فقط، دون 1.3: آمن ويجتاز، لكنك تترك أحدث وأسرع إصدار على الطاولة. معظم الدرجة؛ ويستحق تفعيل 1.3.
• TLS 1.0 أو 1.1 لا يزال مقبولاً: فشل تلقائي، يُقيَّم بصفر ويُعلَّم كحرج — لا يهمّ أن 1.2/1.3 يعملان أيضاً، لأن الإصدارات المعطوبة هي الباب المفتوح. هذا ما يجب إصلاحه.

الصفر

بمجرد اختيار إصدار، يختار TLS صفراً — الخوارزمية الفعلية التي تشوّش البيانات. معظم الأصفار الحديثة قوية. وحفنة منها معطوبة ويجب ألّا تُستخدم أبداً: RC4 (تشويشه منحاز ويُسرّب النصّ الصريح)، وDES (مفتاحه قصير جداً بحيث يمكن كسره بالقوة الغاشمة)، و3DES (معرّض لهجوم “Sweet32”)، بالإضافة إلى NULL (لا تشفير على الإطلاق)، وأصفار EXPORT-grade (ضعيفة عمداً — هجوما FREAK وLogjam)، والأصفار المجهولة (لا فحص هوية، فيمكن لمنتحِل الجلوس في المنتصف).

يفعل فحص الأصفار لدينا أمرين. أولاً ينظر في الصفر الذي تفاوض عليه خادمك معنا فعلاً. ثم — وهذا الجزء المهمّ — يحاول بشكل فعّال إجراء مصافحة باستخدام عدة أصفار معروفة بأنها معطوبة (RC4 و3DES وEXPORT وNULL والمتغيرات المجهولة). يمكن لخادم أن يختار صفراً قوياً حين يتحدّث إلى عميل حديث لكنه لا يزال يقبل صفراً ضعيفاً إن أصرّ مهاجم — وذلك خطر نزول حقيقي. وإذا قبل خادمك أي صفر محظور، يُعلِّمه الفحص؛ وقبول صفر حرج (مثل RC4 أو NULL) فشل. (على TLS 1.3 لا شيء للقلق بشأنه هنا — فذلك الإصدار أزال كل صفر ضعيف بالتصميم، فتُتخطّى السبر.)

الإضافات الثلاث للعلم

ثلاثة بنود ذات صلة يُبلَّغ عنها لكنها لا تؤثر في درجتك — تُعلَّم للعلم لأنه لا يمكن التحقق منها بموثوقية من الخارج، وعلى أي خادم أو CDN حديث تُتولّى أصلاً بشكل صحيح:

• ضغط TLS (هجوم CRIME): ميزة قديمة قد تتيح لمهاجم، إن تُركت مفعّلة، استخلاص ملفات تعريف ارتباط الجلسة. عُطّلت افتراضياً في كل خادم ويب حديث منذ أكثر من عقد، فهي عملياً غير ذات شأن اليوم.
• OCSP stapling: تحسين للأداء والخصوصية حيث يجلب خادمك مسبقاً دليلاً على أن شهادته لم تُلغَ، فلا يضطر كل زائر لسؤال جهة الشهادات بنفسه (وهو أبطأ ويُسرّب بيانات التصفّح). وشبكات CDN مثل Cloudflare تفعل هذا تلقائياً.
• إعادة التفاوض الآمنة: إصلاح لخلل قديم (CVE-2009-3555) أتاح للمهاجمين حقن بيانات في جلسة. أزال TLS 1.3 إعادة التفاوض كلياً، فهي غير ذات شأن هناك، وخوادم TLS 1.2 الحديثة تنفّذ الإصلاح افتراضياً.

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

كيفية الإصلاح (مجاناً، ~30 دقيقة)

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

النهج الموثوق الأبسط هو توليد إعداد معروف بأنه سليم بدلاً من كتابته يدوياً: الصق نوع خادمك في مولّد إعدادات SSL من Mozilla على https://ssl-config.mozilla.org/ واختر ملف “Intermediate” (توافق واسع) أو “Modern” (TLS 1.3 فقط، إن لم تكن بحاجة لدعم أي شيء قديم). فيُخرِج أسطر ssl_protocols وssl_ciphers الصحيحة لك.

حسب المنصة:

1. Cloudflare أو مضيف مُدار — عادة نقرة أو نقرتان. في Cloudflare: SSL/TLS ← Edge Certificates ← Minimum TLS Version ← TLS 1.2، ومجموعات الأصفار هناك تُدار لك (لن تعرض المنصة أصفاراً محظورة). ومعظم المضيفين المُدارين ومنشئي المواقع (Squarespace، Wix، Shopify، مضيفو WordPress الحديثون) يفرضون أصلاً TLS 1.2+ بأصفار قوية — فقط تأكد من عدم وجود خيار “legacy TLS” أو “توافق المتصفحات القديمة” لا يزال مفعّلاً.
2. Nginx. اضبط الإصدارات الحديثة فقط وقائمة أصفار قوية صريحة، ثم أعِد التحميل:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   (يتطلب TLS 1.3 وجود OpenSSL 1.1.1+ على الجهاز.)
3. Apache. عطّل الإصدارات القديمة وثبّت قائمة أصفار قوية، ثم أعِد التشغيل:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. استخدم أداة IIS Crypto المجانية (أو إعدادات السجل المكافئة) لتعطيل TLS 1.0 و1.1، وتعطيل أصفار RC4/DES/3DES/NULL/EXPORT، وترك TLS 1.2 و1.3 بأصفار قوية مفعّلة. وقالب “Best Practices” في الأداة يفعل كل هذا بنقرة واحدة.
5. الإضافات للعلم (اختياري، مجاني). إن أردت المسح النظيف الكامل: على Nginx أضِف ssl_stapling on; ssl_stapling_verify on; (مع سطر resolver) لـ OCSP stapling؛ وعلى Apache، SSLUseStapling On. أمّا ضغط TLS وإعادة التفاوض الآمنة فهما آمنان افتراضياً على الخوادم الحديثة — لا إجراء مطلوب. وعلى Cloudflare تُتولّى الثلاثة تلقائياً.
6. تحقّق، ثم أعِد الفحص هنا. تأكد من بقاء الإصدارات والأصفار الآمنة فقط — مثلاً بـ nmap --script ssl-enum-ciphers -p 443 yourdomain.com، أو اختبر بأدوات https://ssl-config.mozilla.org/ المرتبطة — ثم أعِد إجراء هذا الفحص. وحيثما أمكن، فعّل TLS 1.3 إلى جانب 1.2: فهو أسرع وأأمن.

الأخطاء الشائعة

• “لدينا قفل، فنحن على ما يرام.” القفل يثبت فقط أن اتصالاً آمناً موجود. ولا يقول شيئاً عمّا إذا كان إصدار قديم أو صفر محظور لا يزال مقبولاً في الخلفية — وهو بالضبط الثغرة التي تعثر عليها هذه الفحوص.
• إصلاح الإصدار لكن ليس الأصفار (أو العكس). تعطيل TLS 1.0/1.1 لا يزيل تلقائياً RC4 أو 3DES، وتثبيت أصفار قوية لا يعطّل تلقائياً الإصدارات القديمة. اضبط كليهما — والإعداد المولَّد أعلاه يفعل ذلك.
• ترك مفاتيح “legacy” أو “توافق المتصفحات القديمة” مفعّلة. لدى كثير من المضيفين وشبكات CDN خيار يُعيد بهدوء تفعيل الإصدارات المعطوبة أو الأصفار الضعيفة “للتوافق.” وهو لا يساعد زائراً حقيقياً أبداً تقريباً ويسبّب هذه النتيجة مباشرة.
• نسيان إعادة تحميل/تشغيل الخادم فعلاً. لا تسري تغييرات الإعداد حتى يُعاد تحميل خادم الويب — سبب شائع بشكل مفاجئ لبقاء موقع “أُصلِح” فاشلاً في إعادة الفحص.
• إعداد خادم واحد دون البقية. إذا كنت تشغّل موازِن أحمال، أو عدة خوادم ويب، أو نطاقات فرعية منفصلة (متجر، مدوّنة، تطبيق)، فإن كل نقطة نهاية TLS تحتاج الإعداد نفسه — والأضعف هو ما يستهدفه المهاجم.

ما يجب تذكّره

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

الأسئلة الشائعة