التعليمات: إبطال الشهادة الرقمية

كانت المحاولة الأولية لمراجع التصديق لنشر حالة الإبطال للشهادات الصادرة عن طريق قوائم إبطال الشهادات (CRLs). قائمة الشهادات الباطلة (CRL) هي ببساطة قائمة بجميع الشهادات التي أبطلها المرجع المصدق قبل انتهاء صلاحيتها المجدولة. يتم تحديثها بشكل دوري بواسطة CAs ، وكان مطلوب من المتصفحات مراجعتها قبل كل اتصال HTTPS. بمرور الوقت ، نما حجم CRLs ، كما فعلت مهمة كل متصفح يقوم بمراجعتها. مع تزايد الوقت اللازم لتنزيل وتحليل CRL كبيرة (ومتنامية) ، زادت أيضًا حالات التأخير بالنسبة للمستخدم. في محاولة للتخفيف من هذه المشكلات ، قامت المستعرضات و CAs بتطوير وتنفيذ بروتوكول حالة الشهادة عبر الإنترنت (OCSP).

• بروتوكول حالة الشهادة عبر الإنترنت (OCSP) هو بروتوكول الإنترنت الذي تستخدمه متصفحات الويب لتحديد حالة إبطال SSL /TLS الشهادات التي توفرها مواقع HTTPS. بينما SSL /TLS يتم دائمًا إصدار الشهادات بتاريخ انتهاء الصلاحية ، وهناك ظروف معينة يجب فيها إبطال الشهادة قبل انتهاء صلاحيتها (على سبيل المثال ، إذا كان المفتاح الخاص المرتبط بها قد تعرض للاختراق). لذلك ، يجب دائمًا التحقق من الصلاحية الحالية لشهادة موقع الويب من قبل العملاء بغض النظر عن تاريخ انتهاء صلاحيتها.

يعمل OCSP في أبسط أشكاله على النحو التالي:

1. يتلقى متصفح الويب شهادة من موقع ويب HTTPS.
2. يرسل متصفح الويب طلبًا إلى مستجيب OCSP ، وهو خادم يتم تشغيله بواسطة المرجع المصدق (CA) الذي أصدر الشهادة.
3. تشير الاستجابة الموقعة من المستجيب OCSP إلى المتصفح إلى ما إذا كانت الشهادة صالحة أو تم إبطالها.

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

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

بينما تم تقديمه في البداية لحل مشاكل النطاق الترددي والتحجيم لقوائم إبطال الشهادات (CRLs) ، قدم OCSP العديد من مشكلات الأداء والأمان الخاصة به والتي يتم معالجتها حاليًا من خلال تدبيس OCSP. في تدبيس OCSP:

1. يطلب خادم الويب ويحصل على استجابة OCSP موقعة لشهادته من مستجيب OCSP ، والتي يمكن تخزينها مؤقتًا لمدة تصل إلى 7 أيام.
2. يشتمل الخادم على استجابة OCSP المخبأة جنبًا إلى جنب مع (أو "التدبيس إلى") شهادته في استجابات HTTPS لمتصفحات الويب.
3. لمنع هجوم محتمل يقدم فيه موقع ويب شهادة مسروقة تم إبطالها بدون استجابة OCSP أساسية ، قد يتم إصدار الشهادات ذات ملحق أساسي ، مما يفرض تدبيس OCSP للشهادة.

بدافع من التحركات الضارة من قبل مهاجمي MITM ، قدمت CAs وبائعي المستعرضات امتدادًا لشهادات SSL المعروفة باسم يجب أن تدبيس OCSP (المعرفة في RFC 7633، على الرغم من عدم الإشارة إليها باسم "OCSP Must-Staple"). 

يتطلب OCSP Must-Staple تثبيت OCSP للشهادة. إذا اتصل مستعرض بشهادة بدون تدبيس OCSP ، فسيتم رفضه. لا يقتصر الأمر على Must-Staple في التخفيف من خطر هجمات الرجوع إلى الإصدار السابق ، بل يقلل أيضًا من حركة المرور غير الضرورية إلى مستجيبين OCSP في CA ، مما يحسن الاستجابة والأداء العام لـ OCSP.

CRLite هو معيار تم اقتراحه حديثًا من شأنه إرسال معلومات حول جميع SSL المبطل /TLS الشهادات مباشرة إلى المتصفحات. من المحتمل أن يؤدي ذلك إلى قطع جميع العمليات المرهقة والاتصالات غير الموثوقة بين المتصفحات والمراجع المصدقة من خلال دمج المعلومات حول المراجع المصدقة التي تم إلغاؤها مباشرة في المستعرضات. 
قد يكون مصدر القلق الرئيسي هو الكم الهائل من المعلومات التي يتم تخزينها ، ورؤية كيف كان حجم CRLs الكبير والمتزايد وما هو من المشكلات الأساسية في عمليات OCSP. يستخدم CRLite مرشحات الإزهار لضغط كميات كبيرة من البيانات ، مما يجعلها أكثر قابلية للإدارة للمتصفحات. 

إذا كانت الشهادة جديدة للغاية، وهذا يعني أنه لم يتم تضمينه بعد في أي تحديثات ، فإن المتصفح سيستخدم بعد ذلك OCSP (تدبيس أو استعلام نشط).