يمكن لإعدادات SSL/TLS الخاطئة أن تجعل خدمة موجودة أصلًا أكثر عرضة للاعتراض أو التلاعب أو الانقطاع، حتى لو كان الموقع يعرض HTTPS بصورة طبيعية. المشكلة لا تقتصر على انتهاء صلاحية الشهادة؛ فقد تكون في إصدار TLS قديم، أو شهادة لا تطابق اسم النطاق، أو سلسلة ثقة غير صحيحة، أو بقاء HTTP متاحًا بطريقة غير آمنة، أو تحميل موارد عبر اتصال غير مشفر.
ومن المهم توضيح المصطلحات أولًا: اسم SSL ما زال شائعًا تجاريًا، لكن SSL 2.0 وSSL 3.0 بروتوكولات قديمة وغير آمنة. الاتصالات الحديثة التي نطلق عليها عادةً "SSL" تستخدم في الواقع TLS.
كما أن سوء إعداد TLS لا يعني دائمًا إنشاء أصل أو منفذ جديد داخل سطح الهجوم. في حالات كثيرة يكون الوصف الأدق أنه يزيد قابلية استغلال أصل موجود أو يرفع مستوى التعرض الأمني له. أما تشغيل بروتوكولات وخيارات قديمة لا يحتاجها النظام فعلًا، فقد يوسع سطح الهجوم نفسه بإبقاء مسارات توافق إضافية متاحة.
ما الذي يفعله TLS فعليًا؟
يعمل TLS بين التطبيق وطبقات النقل لتوفير ثلاث خصائص أساسية عند استخدامه بصورة صحيحة: سرية البيانات أثناء انتقالها، سلامتها من التعديل، وتمكين العميل من التحقق من هوية الخادم اعتمادًا على الشهادة وسلسلة الثقة.
إذا كنت تحتاج إلى فهم العلاقة بين هذه الطبقات وTCP وDNS وHTTP، يشرح دليل أساسيات الشبكات وTCP/IP الخلفية الشبكية التي تعمل فوقها اتصالات HTTPS.
بحسب إرشادات OWASP الحالية لتأمين TLS، ينبغي لتطبيقات الويب الحديثة الاعتماد افتراضيًا على TLS 1.3، مع دعم TLS 1.2 عند الحاجة إلى التوافق. أما TLS 1.0 وTLS 1.1 فقد جرى إهمالهما رسميًا في RFC 8996.
ما أشهر أخطاء SSL/TLS التي يجب البحث عنها؟
| الخطأ | ما المشكلة؟ | الأثر المحتمل |
|---|---|---|
| دعم SSL أو TLS 1.0/1.1 | الإبقاء على بروتوكولات قديمة لم تعد مناسبة للويب الحديث | زيادة فرص سوء التهيئة أو استخدام آليات تشفير قديمة |
| مجموعات تشفير ضعيفة | السماح بخيارات أقدم أو غير مناسبة ضمن TLS 1.2 | خفض مستوى حماية الاتصال وتوسيع الخيارات التي يجب تأمينها |
| شهادة منتهية الصلاحية | انتهاء فترة صلاحية شهادة الخادم | تحذيرات أو رفض الاتصال وتعطل الخدمة |
| Hostname Mismatch | اسم النطاق المطلوب غير مغطى بالشهادة | فشل التحقق من هوية الخادم |
| سلسلة شهادات غير صحيحة | غياب أو خطأ في Intermediate Certificates | فشل الثقة على بعض العملاء والأجهزة |
| HTTP دون حماية مناسبة | اعتماد التحويل إلى HTTPS وحده دون سياسة HSTS مناسبة | إمكانية استهداف الاتصال الأول بهجمات Downgrade أو SSL Stripping |
| Mixed Content | صفحة HTTPS تطلب موارد عبر HTTP | إمكانية اعتراض المورد غير المشفر أو تعديله، أو قيام المتصفح بحظره |
| ضعف إدارة دورة حياة الشهادات | غياب الجرد والأتمتة والتنبيه قبل انتهاء الصلاحية | انقطاعات مفاجئة وأصول منسية خارج المراقبة |
هل TLS 1.0 وTLS 1.1 ما زالا مقبولين؟
لا ينبغي لخدمة ويب حديثة الاحتفاظ بهما لمجرد التوافق الافتراضي. يوضح IETF في RFC 8996 أن TLS 1.0 وTLS 1.1 أصبحا Historic، وأن إزالة الإصدارات القديمة تقلل سطح الهجوم وفرص سوء التهيئة.
القاعدة العملية لخدمات الويب العامة هي:
- استخدم TLS 1.3 متى كان مدعومًا.
- احتفظ بـTLS 1.2 إذا كنت تحتاج إلى توافق مع عملاء ما زالوا يستخدمونه.
- عطّل SSL 2.0 وSSL 3.0 وTLS 1.0 وTLS 1.1.
- لا تخفض أمان نقطة النهاية الرئيسية من أجل أجهزة قديمة انتهى دعمها؛ اعزل حالات التوافق الاستثنائية عندما تكون هناك ضرورة حقيقية.
كيف يمكن لسوء إعداد TLS أن يؤدي إلى هجوم MITM؟
هجوم Man-in-the-Middle أو MITM يعني وجود طرف قادر على اعتراض الاتصال بين العميل والخادم ومحاولة مراقبته أو تغييره. يمكنك الرجوع إلى شرح هجوم الرجل في المنتصف ومصطلحات الأمن السيبراني لفهم هذا النوع من الهجمات بصورة أوسع.
TLS المصمم والمهيأ بصورة صحيحة يجعل اعتراض اتصال HTTPS وتعديله أمرًا صعبًا لأن العميل يتحقق من شهادة الخادم ويُنشئ قناة مشفرة ومحمية من التلاعب. لكن الخطر يرتفع عندما تعتمد البنية على HTTP في جزء من المسار، أو تسمح للمستخدم بالوصول الأول عبر HTTP دون حماية إضافية، أو تكون الثقة بالشهادة مكسورة.
وهنا يجب تجنب مبالغة شائعة: وجود شهادة منتهية الصلاحية لا يجعل المتصفح يتحول تلقائيًا إلى HTTP ولا يعني وحده أن المهاجم يستطيع فك تشفير الاتصال. المتصفحات الحديثة تعرض خطأً أو تحذيرًا، وقد تمنع الوصول بحسب الحالة والسياسة. الخطر المباشر هنا غالبًا هو فقدان الثقة أو تعطّل الخدمة، إضافة إلى خطر اعتياد المستخدمين على تجاهل تحذيرات الشهادات.
لماذا لا يكفي تحويل HTTP إلى HTTPS؟
لنفترض أن المستخدم كتب:
http://example.com
يمكن للخادم الرد بتحويله إلى:
https://example.com
هذا أفضل من إبقاء الموقع على HTTP، لكنه يعني أن الطلب الأول بدأ أصلًا عبر اتصال غير مشفر. يوضح دليل TLS لدى MDN أن مهاجمًا موجودًا على مسار الاتصال قد يحاول استهداف هذه المرحلة لمنع الانتقال إلى HTTPS، وهي الفكرة التي ترتبط بهجمات SSL Stripping.
الحل الأساسي هو استخدام HTTP Strict Transport Security أو HSTS بعد التأكد من جاهزية النطاق.
مثال:
Strict-Transport-Security: max-age=31536000; includeSubDomains
يخبر HSTS المتصفح بأن هذا المضيف يجب الوصول إليه باستخدام HTTPS فقط. وفي الزيارات اللاحقة يستطيع المتصفح ترقية طلب HTTP إلى HTTPS قبل إرسال الطلب غير المشفر.
لكن تفعيل includeSubDomains أو الدخول في HSTS Preload دون مراجعة البنية قد يؤدي إلى تعطيل نطاقات فرعية لا تدعم HTTPS. لذلك يجب جرد جميع النطاقات الفرعية واختبارها قبل فرض السياسة على نطاق واسع. توضح وثائق HSTS هذه الآلية وقيودها بالتفصيل.
ما خطر Mixed Content في صفحة تعمل عبر HTTPS؟
لا يكفي أن تكون الصفحة الرئيسية نفسها عبر HTTPS. إذا كانت الصفحة تطلب JavaScript أو CSS أو صورًا أو موارد أخرى عبر HTTP، يظهر ما يسمى Mixed Content.
المورد المنقول دون حماية يمكن نظريًا اعتراضه أو تعديله من طرف موجود على مسار الشبكة. ويكون الخطر أكبر مع الموارد النشطة مثل JavaScript لأنها تستطيع التأثير في محتوى الصفحة وسلوكها.
المتصفحات الحديثة تخفف جزءًا كبيرًا من هذه المشكلة؛ فهي تحظر أنواعًا خطرة من Mixed Content وتحاول ترقية بعض الموارد تلقائيًا إلى HTTPS. لكن ذلك لا يجعل إبقاء روابط HTTP داخل الموقع ممارسة صحيحة. توصي وثائق MDN الخاصة بالمحتوى المختلط بإزالة هذه الطلبات والاعتماد على موارد آمنة.
ويمكن، عند الحاجة أثناء ترحيل موقع قديم، استخدام سياسة CSP مثل:
Content-Security-Policy: upgrade-insecure-requests
لكن هذه السياسة لا تُعد بديلًا عن HSTS لتأمين الانتقال الأول من HTTP إلى HTTPS.
الشهادات المنتهية أصبحت مشكلة تشغيلية أكبر في 2026
هناك تغير مهم في Web PKI يجعل الاعتماد على التجديد اليدوي أقل ملاءمة من السابق. وفق أحدث Baseline Requirements لدى CA/Browser Forum، أصبح الحد الأقصى لصلاحية شهادات TLS العامة الجديدة 200 يوم اعتبارًا من 15 مارس 2026.
| تاريخ الإصدار | الحد الأقصى لصلاحية شهادة TLS العامة |
|---|---|
| من 15 مارس 2026 | 200 يوم |
| من 15 مارس 2027 | 100 يوم |
| من 15 مارس 2029 | 47 يومًا |
هذه الحدود تخص شهادات TLS الموثوقة علنًا ضمن Web PKI ولا تعني تلقائيًا أن كل شهادة داخلية في Private PKI تخضع للجدول نفسه.
النتيجة العملية هي أن إدارة الشهادات يجب أن تنتقل من مهمة دورية يتذكرها شخص إلى عملية قابلة للأتمتة والمراقبة. فكلما قصرت مدة الصلاحية، ارتفعت أهمية الاكتشاف التلقائي والتجديد الآلي والتنبيه عند فشل التجديد.
أين تدخل EASM في المشكلة؟
إدارة سطح الهجوم الخارجي أو External Attack Surface Management لا تقوم بإصلاح TLS تلقائيًا بمجرد نشرها، لكنها تعالج مشكلة مختلفة ومهمة: معرفة كل الأصول المواجهة للإنترنت التي تحتاج إلى الفحص أصلًا.
في مؤسسة لديها عشرات النطاقات والنطاقات الفرعية وواجهات API وعناوين IP وخدمات سحابية، قد تكون المشكلة الأخطر شهادة موجودة على نطاق تجريبي نسيه الفريق وليس الشهادة الموجودة على الموقع الرئيسي.
على سبيل المثال، توضح وثائق Microsoft Defender EASM أن المنصة تكتشف وترسم الأصول الخارجية باستمرار، بينما تعرض تفاصيل الشهادات المكتشفة مثل تاريخ الإصدار والانتهاء وخوارزمية التوقيع. كما توفر مرشحات للشهادات المنتهية أو Self-Signed وغيرها.
يمكن لمنصة EASM أن تساعد في:
- اكتشاف نطاقات وخوادم وأصول خارجية لم تكن مدرجة في الجرد المركزي.
- إنشاء Inventory للشهادات المرتبطة بهذه الأصول.
- اكتشاف شهادات منتهية أو قريبة من الانتهاء.
- البحث عن خوارزميات توقيع أو خصائص قديمة ضمن الشهادات.
- تحديد أصل جديد ظهر على الإنترنت دون المرور بعملية النشر المعتادة.
- متابعة التغيرات التي تحدث في سطح الهجوم مع مرور الوقت.
لكن EASM ليس بديلًا عن إدارة الشهادات أو Hardening لخادم الويب أو مراجعة إعدادات TLS. دوره هو الرؤية والاكتشاف والمساعدة في ترتيب المخاطر، ثم تحتاج فرق البنية التحتية أو DevOps والأمن إلى معالجة الإعداد نفسه.
كيف تفحص إعدادات TLS بصورة عملية؟
1. ابدأ بجرد الأصول لا بفحص الموقع الرئيسي فقط
احصر كل ما هو متاح من الإنترنت: النطاق الرئيسي، النطاقات الفرعية، APIs، بوابات الإدارة المصرح بعرضها، VPN Gateways، Load Balancers، Reverse Proxies والخدمات السحابية.
إذا لم يكن لديك Inventory موثوق، فإن نتيجة "الموقع الرئيسي آمن" لا تعني أن المؤسسة كلها آمنة.
2. افحص الإصدارات ومجموعات التشفير والشهادة
يمكن استخدام Qualys SSL Labs Server Test لإجراء تحليل خارجي لخادم HTTPS عام ومعرفة البروتوكولات والشهادة وبعض خصائص التهيئة.
في البيئات المؤسسية، يجب أن يكون هذا جزءًا من عملية مستمرة، لا اختبارًا يدويًا مرة واحدة فقط.
3. عطّل البروتوكولات القديمة
اجعل TLS 1.3 الخيار الافتراضي، واسمح بـTLS 1.2 عندما يتطلب التوافق ذلك. لا تبقِ TLS 1.0 أو1.1 أوSSL القديمة مفعلة دون ضرورة مدروسة.
4. راجع الشهادة وسلسلة الثقة
تحقق من:
- أن الشهادة ما زالت ضمن فترة الصلاحية.
- أن أسماء النطاقات الصحيحة موجودة في Subject Alternative Name.
- أن الخادم يرسل Intermediate Certificates المطلوبة.
- أن الشهادة صادرة عن جهة موثوقة بالنسبة للعملاء المستهدفين.
- أن خوارزميات المفاتيح والتوقيع تلائم المتطلبات الحالية.
- أن المفتاح الخاص محمي ولا يتم نسخه عشوائيًا بين الخوادم.
5. أتمت التجديد وراقب فشل الأتمتة
أتمتة التجديد تقلل خطر الخطأ البشري، لكنها ليست كافية وحدها. قد يفشل ACME أو Deployment أو إعادة تحميل الخدمة. لذلك يجب مراقبة تاريخ انتهاء الشهادة الفعلية التي يقدمها الخادم للمستخدم والتنبيه قبل الوصول إلى مرحلة الخطر.
6. طبّق HTTPS على الموقع كاملًا
لا تقتصر الحماية على صفحة تسجيل الدخول. يجب أن تنتقل جميع الصفحات والموارد الحساسة والعادية عبر HTTPS حتى لا تترك أجزاء من الجلسة قابلة للاعتراض أو التعديل.
7. انشر HSTS بصورة مدروسة
ابدأ بعد التأكد من أن HTTPS يعمل بصورة صحيحة. اختبر النطاقات الفرعية قبل استخدام includeSubDomains، ولا تضف الموقع إلى Preload إلا عندما تكون مستعدًا للالتزام بهذه السياسة على المدى الطويل.
8. أزل Mixed Content
ابحث عن أي روابط http:// إلى Scripts أو Stylesheets أو Fonts أو Images أو Downloads وحوّلها إلى مصادر HTTPS حقيقية بدل الاعتماد على المتصفح لإصلاح المشكلة.
9. لا تخلط بين TLS وأمان التطبيق بالكامل
يمكن أن يحصل خادم على أفضل تقييم TLS ومع ذلك يحتوي التطبيق على Broken Access Control أو XSS أو SSRF أو مشكلات في الجلسات. TLS يحمي قناة النقل ولا يصحح منطق التطبيق.
ولهذا يجب أن يكون فحص TLS جزءًا من مراجعة أوسع تجمع بين الأدوات الآلية والاختبار السياقي؛ فهناك ثغرات ومشكلات إعداد قد تفوتها الفحوصات الآلية حتى عندما تبدو البنية الخارجية سليمة ظاهريًا.
قائمة تحقق مختصرة لتقليل مخاطر SSL/TLS
- عطّل SSL 2.0 وSSL 3.0 وTLS 1.0 وTLS 1.1.
- استخدم TLS 1.3 افتراضيًا مع TLS 1.2 للتوافق عند الحاجة.
- راجع Cipher Suites المتاحة في TLS 1.2.
- تأكد من صحة Hostname وسلسلة الشهادة.
- راقب انتهاء الشهادات وأتمت التجديد.
- اختبر التجديد نفسه ولا تفترض أن الأتمتة تعمل دائمًا.
- حوّل HTTP إلى HTTPS.
- فعّل HSTS بعد اختبار البنية والنطاقات الفرعية.
- أزل Mixed Content.
- احمِ المفاتيح الخاصة وقلل توزيعها بين الأنظمة.
- أنشئ Inventory مستمرًا للأصول والشهادات الخارجية.
- استخدم EASM عند الحاجة لاكتشاف الأصول التي قد لا تكون معروفة للفريق.
- أعد الفحص بعد أي تغيير في CDN أوLoad Balancer أوReverse Proxy أوخادم الويب.
الخلاصة
المشكلة في SSL/TLS ليست مجرد وجود شهادة أو ظهور HTTPS في شريط العنوان. الأمان الحقيقي يعتمد على البروتوكول المستخدم، وخيارات التشفير، وصحة الشهادة وسلسلتها، وحماية الانتقال من HTTP، وغياب المحتوى المختلط، وإدارة دورة حياة الشهادات بصورة مستمرة.
ومع انخفاض الحد الأقصى لصلاحية شهادات TLS العامة إلى 200 يوم منذ 15 مارس 2026، ثم إلى 100 يوم في 2027 و47 يومًا في 2029، أصبحت الأتمتة والمراقبة أكثر أهمية من الاعتماد على التجديد اليدوي.
أما EASM فيضيف طبقة مختلفة من الحماية: يساعدك على معرفة أين توجد الأصول والشهادات التي تحتاج إلى المراجعة، بما في ذلك الأصول التي ربما نسيها الفريق. بعد اكتشافها، تبقى المعالجة الفعلية قائمة على Hardening صحيح لـTLS، وإدارة شهادات موثوقة، ومراقبة مستمرة للتأكد من أن الإعداد الآمن لا يتدهور بمرور الوقت.