عندما تضغط على commit، الخاص CI/CD pipeline يتم التشغيل، ويتم اجتياز الاختبارات، ويتم النشر بنقرة واحدة. ثم فجأة، يفشل البناء مع رسالة TLS غامضة.
لا توجد تغييرات في الكود يمكن إلقاء اللوم عليها، ولكن pipeline أحمر. ماذا حدث؟ بالنسبة للعديد من الفرق، غالبًا ما يكون السبب مشكلة أمنية في بروتوكول TLS، مثل انتهاء صلاحية الشهادة، أو ضعف التشفير، أو خطأ في تهيئة الخادم. والخبر السار؟ من السهل اكتشاف هذه المشاكل قبل أن تُعطّل عمليات البناء إذا كنت تعرف كيفية استخدامها. عميل OpenSSL.
ستوضح لك هذه المقالة كيفية تشخيص أخطاء SSL ومنع حدوثها CI/CD pipelineق باستخدام openssl s_clientسنغطي أمثلة حقيقية وتقنيات الأتمتة و guardrails التي تحافظ على عمليات النشر الخاصة بك آمنة.
عندما يكون لديك Pipeline صرخات: فشل TLS حقيقي
فيما يلي مشهد مألوف للعديد من مهندسي DevOps:
bash
$ openssl s_client -connect example.com:443
CONNECTED(00000003)
depth=0 CN = example.com
Verify error:num=10:certificate has expired
أن خطأ SSL يعني أن شهادة نقطة النهاية انتهت صلاحيتها. In CI/CDيؤدي هذا إلى إيقاف عمليات النشر، وكسر اختبارات التكامل، وقد يؤدي إلى حظر الإصدار بأكمله.
والأسوأ من ذلك، أنه إذا تم تجاهل هذه الثغرة الأمنية في بروتوكول TLS، فقد تعرض أنظمة الإنتاج لهجمات الوسيط أو تتسبب في تعطل الخدمة.
لماذا يعد OpenSSL s_client بمثابة سكين تصحيح أخطاء TLS للمطورين
على عكس تحذيرات المتصفح، والتي هي غامضة ويدوية، s_client الخاص بـ OpenSSL يعطي عرضًا خامًا ومفصلاً لمصافحة TLS.
إنه مثالي لـ:
- التحقق من إصدار TLS والتشفير الذي يستخدمه نقطة النهاية
- التحقق من صحة الشهادات وموثوقيتها
- تصحيح أخطاء الاتصالات مباشرة في CI/CD وظيفة
مثال على فحص المصافحة:
bash
openssl s_client -connect service.internal:443 -servername service.internal -tls1_2
ستحصل على رؤية فورية لتفاصيل الشهادة، والشفرات المدعومة، وأي أخطاء SSL أثناء التفاوض. لهذا السبب، تعتبرها العديد من فرق DevSecOps أداة أمان TLS المفضلة.
أخطاء TLS/SSL الشائعة التي تؤدي إلى تعطل CI Pipelines
دعونا نلقي نظرة على الإخفاقات الأكثر احتمالا للظهور في CI/CD، مع أمثلة وتأثيرات قصيرة.
1 شهادات منتهية الصلاحية أو غير صالحة بعد
bash
$ openssl s_client -connect example.com:443
Verify error:num=10:certificate has expired
تأثير: تفشل الاختبارات الآلية عند استخدام إحدى التبعيات لشهادة قديمة. في هياكل الخدمات المصغرة، قد تؤدي شهادة واحدة منتهية الصلاحية في خدمة داخلية إلى إيقاف سلسلة النشر بأكملها.
2 تشفير ضعيف أو بروتوكولات قديمة
bash
openssl s_client -connect app.dev:443 -cipher LOW
تأثير: تفشل بوابات الأمان عندما تدعم الخدمة بروتوكولات TLS 1.0/1.1 أو التشفير الضعيف. يظهر هذا غالبًا أثناء عمليات فحص الامتثال في البيئات الخاضعة للتنظيم.
3 عدم تطابق اسم المضيف والشهادات ذاتية التوقيع
مثال: تستخدم خدمة التجهيز الداخلي شهادة صادرة لـ الخدمة المحلية، ولكن pipeline المكالمات خدمة.تطويربدلاً من ذلك، قد تكون الشهادة موقعة ذاتيًا ولا يثق بها مخزن الثقة الخاص بالمشغل.
تأثير: يفشل التحقق من المصافحة ما لم يتم تجاوزه صراحةً، مما يُشكل خطرًا على بيئة الإنتاج. هذا شائع في استدعاءات واجهة برمجة التطبيقات الداخلية، أو إعدادات الاختبار المحلية، أو بيئات التطوير المُهيأة بشكل خاطئ.
4 سلاسل شهادات غير مكتملة
مثال: شهادة المرحلة تفتقد إلى سلطة تصديق وسيطة.
تأثير: ستفشل عمليات التشغيل التي تحتوي على مخازن ثقة أكثر صرامة في إجراء الاتصالات، مما يتسبب في حدوث فشل متقطع في البناء.
تشخيص فشل TLS في CI/CD مع OpenSSL s_client
الخطوة الأولى: إعادة إنتاج الفشل في CI/CD بيئة.
yaml
- name: Check TLS
run: |
openssl s_client -connect api.prod:443 -servername api.prod </dev/null
يتيح لك هذا الحصول على نسخة كاملة من مصافحة TLS والبروتوكول والتشفير وسلسلة الشهادات وأي أخطاء في التحقق من الصحة.
ابحث عن:
- التحقق من الخطأ رسائل
- إصدارات بروتوكول TLS القديمة
- الوسائط المفقودة في السلسلة
الانتقال إلى الأتمتة:
بمجرد تحديد السبب الجذري، فإن الخطوة التالية هي جعل هذه الفحوصات آلية. التشخيص اليدوي جيد في بعض الأحيان، ولكن بدون أتمتة، ستلاحظ نفس النتيجة. خطأ SSL في آخر pipeline بعد اسابيع.
أتمتة عمليات فحص TLS كإجراء أمني Guardrails
يمكنك تضمين عمليات التحقق من TLS في CI/CD حتى تفشل التكوينات السيئة مبكرًا:
- تنبيه إذا انتهت صلاحية الشهادة في أقل من 30 يومًا
- حظر التشفير الضعيف وإصدارات TLS القديمة
- تتطلب سلاسل الشهادات الكاملة
مثال على السور الواقي:
bash
if openssl s_client -connect $HOST:$PORT </dev/null 2>/dev/null | grep -q "Protocol : TLSv1"; then
echo "❌ Weak protocol detected"
exit 1
fi
نصيحة: قم بتشغيل هذا في مرحلة ما قبل النشر حتى تتمكن من اكتشاف المشكلات قبل دمج الكود.
منع مفاجآت TLS في الإنتاج
لا تحدث مشكلات TLS أثناء عمليات النشر فحسب، بل تنتهي صلاحية الشهادات في أي وقت. لهذا السبب، تُعدّ المراقبة المستمرة أمرًا بالغ الأهمية. ضروري في DevSecOps.
مثال على الفحص المجدول باستخدام GitHub Actions:
yaml
name: TLS Monitor
on:
schedule:
- cron: "0 6 * * *"
jobs:
check-tls:
runs-on: ubuntu-latest
steps:
- name: Check TLS expiration
run: |
EXP_DATE=$(echo | openssl s_client -connect example.com:443 2>/dev/null \
| openssl x509 -noout -enddate | cut -d= -f2)
echo "Certificate expires on: $EXP_DATE"
يمكنك تكييف هذا مع مهام cron أو Jenkins أو Kubernetes CronJobs لفحص نقاط النهاية بشكل مستمر بحثًا عن مشكلات أمان TLS.
مخاطر AppSec الحقيقية الناجمة عن TLS المكسور
لا تمثل تكوينات TLS المكسورة مشكلات بناء فحسب؛ بل إنها تشكل أيضًا مسؤوليات أمنية:
- هجمات MITM إذا كان التشفير ضعيفًا أو مفقودًا
- هجمات خفض مستوى إذا تم السماح بالبروتوكولات القديمة
- مخاطر سلسلة التوريد إذا حدثت عمليات تنزيل الحزمة عبر اتصالات غير آمنة
وضع كل ذلك معًا Guardrails
فكر في هذه العملية على النحو التالي: التشخيص → الأتمتة → التنفيذ.
لماذا Guardrails شيء: In CI/CD, guardrails أوقف تكوينات TLS غير الآمنة قبل نشرها. يمكنها حظر النشر في الحالات التالية:
- شهادة على وشك الانتهاء
- تم تمكين التشفير الضعيف
- يتم استخدام بروتوكول عفا عليه الزمن
مثال: في GitLab CI، تفشل المهمة على الفور إذا استجابت نقطة النهاية باستخدام TLS 1.0، مما يفرض الإصلاح قبل الدمج.
أدوات مثل زيجيني يمكن تمديد هذه guardrails لمسح سلسلة توريد البرامج بأكملها بحثًا عن ثغرات أمان TLS.
جمل مفيدة حول OpenSSL s_client لـ CI
التحقق من انتهاء الصلاحية:
bash
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate
قائمة الشفرات:
bash
openssl ciphers -v 'ALL:eNULL' | column -t
الوجبات الجاهزة النهائية
OpenSSL s_client أكثر من مجرد أمر استكشاف أخطاء وإصلاحها؛ إنها أداة DevSecOps لضمان أمان TLS استباقي. استخدمها لاكتشاف أخطاء SSL قبل أن تُعطّل عمليات البناء، وأتمتتها حتى لا تُفاجأ أبدًا بانتهاء صلاحية الشهادة أو ضعف التشفير مرة أخرى.
