OCSP Stapling وCertificate Transparency

قوائم إبطال الشهادات (CRLs) هي ملفات تنشرها CA وتضمّن فيها جميع الشهادات المُبطلة. وتعاني CRLs من عدة مشكلات: فهي تكبر بمرور الوقت، ويجب على العملاء تنزيلها كاملةً، وتتمتع بحداثة محدودة لأنها تُنشر وفق جدول زمني، كما أن المتصفحات كانت تاريخيًا تتعامل مع فشل جلب CRL بقبول الشهادات، مما جعل الإبطال غير موثوق عمليًا.

يتيح بروتوكول حالة الشهادة عبر الإنترنت (OCSP، وفق RFC 6960) للعملاء الاستعلام لحظيًا من مستجيب OCSP التابع لـCA عن حالة إبطال شهادة محددة. وتوضح استجابة OCSP ما إذا كانت الشهادة "good" أو "revoked" أو "unknown"، وتكون موقَّعة من CA. وهذا أكثر كفاءة من تنزيل CRL كاملة.

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

تحل آلية إرفاق OCSP ‏(RFC 6066) مشكلة الخصوصية بجعل الخادم يجلب استجابة OCSP مسبقًا ويخزنها مؤقتًا. وأثناء مصافحة TLS، يُرفق الخادم هذه الاستجابة المخزنة مؤقتًا بالمصافحة، ويسلّمها مباشرةً إلى العميل. وهكذا يحصل العميل على حالة إبطال حديثة دون الاتصال بـCA مباشرةً.

يتطلب إعداد إرفاق OCSP في Nginx إضافة ما يلي إلى كتلة الخادم: "ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8;". ويوفر ssl_certificate_by_lua_block أو التوجيه ssl_trusted_certificate السلسلة اللازمة للتحقق. أما Apache فيتطلب "SSLUseStapling on" داخل VirtualHost. ويخزّن كلا الخادمين الاستجابة مؤقتًا ويحدّثانها قبل انتهاء صلاحيتها.

يخبر امتداد OCSP Must-Staple في X.509 ‏(RFC 7633) المتصفحات بأن خادم هذه الشهادة سيرفق دائمًا استجابة OCSP. وإذا اتصل متصفح بالخادم ولم يتلقَّ استجابة مرفقة، فإنه يرفض الاتصال. ويمنع ذلك مهاجمًا لديه شهادة مُبطلة من حجب استجابات OCSP لإجبار المتصفح على قبول الشهادة عند تعذر التحقق.

شفافية الشهادات (CT) نظام يُطلب فيه من جميع CA الموثوقة للعامة تسجيل كل شهادة تصدرها في سجلات متاحة للتدقيق العام ولا تسمح إلا بالإضافة، وذلك قبل تسليم الشهادة. وتتيح هذه السجلات لمالكي النطاقات والباحثين وخدمات المراقبة اكتشاف الشهادات التي أُصدرت بشكل خاطئ أو التي تم الحصول عليها احتياليًا لأي نطاق.

عندما ترسل CA شهادة إلى سجل CT، يعيد السجل طابعًا زمنيًا موقَّعًا للشهادة (SCT). ويُعد SCT وعدًا موقَّعًا تشفيريًا بأن الشهادة سُجّلت. ويمكن تضمين SCTs في الشهادة نفسها، أو تسليمها عبر امتداد TLS، أو إرفاقها باستجابة OCSP. وتتطلب Chrome طابعَي SCT على الأقل للثقة بالشهادة.

تطلب Google Chrome شفافية الشهادات لجميع شهادات TLS الموثوقة للعامة منذ أبريل 2018. وترفض Chrome الشهادات التي لا تحتوي على SCTs صالحة، وتعرض خطأً في الشهادة. ويفرض هذا المتطلب عمليًا تسجيل CT من جانب جميع CA الكبرى، إذ لا يمكن لأي CA أن تعمل كـCA عامة إذا كانت Chrome ترفض شهاداتها.

تتيح سجلات CT لأي شخص مراقبة الشهادات الصادرة لنطاقه. وتسمح خدمات مثل crt.sh وFacebook's CT Monitor لمالكي النطاقات بالبحث في جميع سجلات CT عن الشهادات التي يظهر نطاقهم في حقلي subject أو SAN. ويصبح إصدار شهادة غير مصرّح بها، مثل إصدارها من CA مخترقة أو عبر اختطاف BGP، قابلًا للاكتشاف خلال ساعات.

تدير سجلات CT عدة مؤسسات مستقلة، منها Google (Argon وXenon) وCloudflare (Nimbus) وDigiCert وSectigo وغيرها. ويمنع تعدد مشغلي السجلات أي جهة واحدة من حجب شهادة مسجَّلة. وتتطلب المتصفحات SCTs من سجلات موجودة في قائمتها المعتمدة، مما يحافظ على ضبط جودة السجلات الموثوقة.

ما المشكلة التي يحلها إرفاق OCSP مقارنةً بـOCSP القياسي؟

تكون CRLs كبيرة وقديمة؛ ويوفر OCSP إبطالًا لحظيًا، لكنه يسرّب بيانات التصفح إلى CA. ويسلّم إرفاق OCSP حالة الإبطال التي جُلبت مسبقًا أثناء مصافحة TLS، مما يحافظ على الخصوصية. ويمنع OCSP Must-Staple تجاوز التحقق الذي يقبل الشهادة عند تعذر الوصول إلى خدمة الإبطال. وتسجّل شفافية الشهادات جميع الشهادات الصادرة، مما يتيح اكتشاف الشهادات المُصدرة بالخطأ عبر SCTs. وتتطلب Chrome استخدام CT منذ عام 2018.