OCSP stapling بالتفصيل (ولماذا هو اختياري)

مشكلة OCSP العادي

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

إن كان المستجيب بطيئًا أو غير قابل للوصول، فإما أن يتجاهل المتصفح الفحص أو يحجب الموقع، حسب العميل. لا هذا ولا ذاك جيد.

ما الذي يغيّره stapling

مع stapling يجلب الخادم بنفسه استجابة OCSP الموقّعة، ويخزّنها، ويرفقها بمصافحة TLS. يحصل المتصفح على جواب الإبطال دون الاتصال بأحد: لا رحلة إضافية ولا تسريب.

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

التفعيل والتحقق

على nginx يحتاج stapling إلى resolver وملف السلسلة، وإن غاب أحدهما فلن يفعل شيئًا بصمت. على Apache يجب أن يكون توجيه الذاكرة على مستوى الخادم. بعد إعادة التحميل، تحقق من الخارج — سطر إعداد موجود لكنه لا يعمل يبدو مطابقًا لسطر غائب.

# nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

# verify from outside — look for a stapled response, not just "OCSP response: none"
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A3 "OCSP Response Status"

لماذا لا يُشترط لـ A+

stapling تحسين للخصوصية والتأخير، لا لقوة البروتوكول. خادم لا يستخدم stapling ليس أقل أمانًا بالطريقة التي يكون بها خادم يعرض TLS 1.0. يتعامل معه CertH كإشارة إيجابية في قسم صحة الإعداد، لكنه لا يشترطه لأعلى تقدير.

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

FAQ