إلغاء الشهادة

توجد ثلاث بنى رئيسية لكيفية وصول العملاء إلى حالة الإلغاء: البنية القائمة على السحب ، حيث يسترجع العملاء حالة الإلغاء عند وقت التحقق؛ والبنية القائمة على الدفع ، حيث يسترجع العملاء حالة الإلغاء قبل التحقق ويخزنونها مؤقتًا؛ والبنية المدعومة بالشبكة ، حيث يتم دمج التحقق من الإلغاء بشكل وثيق مع بروتوكول TLS وقد لا تكون هناك حاجة إلى عمليات تحقق منفصلة. ^{[ 28 ]}

عادةً ما يُعاني التحقق القائم على السحب من مشاكل في زمن الاستجابة والتوافر. وتقوم الأجهزة التي تُجري هذا النوع من التحقق بتخزين الاستجابات مؤقتًا لفترة قصيرة. ولا يُضيف التحقق القائم على السحب فقط، مع استخدام خاصية "الفشل اللين"، أي مستوى أمان إضافي. ^{[ 29 ]}

يُعدّ التحقق القائم على الدفع أقل كفاءة في استخدام النطاق الترددي من التحقق القائم على السحب، ولكنه يوفر توافرًا وخصوصية أفضل. يمكن استخدام طرق مختلفة لكل شهادة على حدة، مما يسمح بضبط المفاضلة بدقة: يُجري كل من متصفح جوجل كروم وموزيلا فايرفوكس عمليات تحقق قائمة على الدفع على مجموعة صغيرة من الشهادات الهامة. ^{[ 29 ]}

قائمة إبطال الشهادات (CRL) تسرد الشهادات الملغاة. ويتم التحقق من صحتها تشفيرياً بواسطة هيئة إصدار الشهادات. ^{[ 30 ]}

تعاني قوائم إبطال الشهادات (CRLs) من مشاكل في قابلية التوسع، وتعتمد على امتلاك العميل لوصول كافٍ إلى الشبكة لتنزيلها قبل التحقق من حالة الشهادة. ^{[ 10 ]}

تحتوي قائمة إبطال الشهادات (CRL) على معلومات حول جميع الشهادات التي ألغتها جهة إصدار الشهادات، مما يعني أن الموزعين والعملاء يتحملون تكاليف نقل معلومات قد تكون غير ذات صلة. ^{[ 31 ]} وجدت دراسة أجريت عام 2015 أن متوسط ​​حجم قائمة إبطال الشهادات (CRL) للشهادة الواحدة يبلغ 51 كيلوبايت، بينما بلغ حجم أكبر قائمة إبطال شهادات 76 ميجابايت. ^{[ 2 ]}

يسمح بروتوكول حالة الشهادة عبر الإنترنت (OCSP) للعملاء بالاستعلام بشكل تفاعلي من خادم ( مستجيب OCSP ) عن حالة الشهادة، ويتلقون ردًا موثقًا تشفيرًا من قِبل جهة إصدار الشهادة. ^{[ 30 ]} وقد صُمم هذا البروتوكول لمعالجة المشكلات المتعلقة بقوائم إبطال الشهادات (CRLs). ^{[ 31 ]} عادةً ما يكون حجم استجابة OCSP أقل من 1 كيلوبايت. ^{[ 32 ]}

يعاني بروتوكول OCSP من مشاكل في قابلية التوسع. فهو يعتمد على توفر اتصال الشبكة لدى العميل وقت التحقق من حالة إبطال الشهادة؛ علاوة على ذلك، يجب أن يكون مُستجيب OCSP متاحًا وأن يُنتج استجابات قابلة للاستخدام، وإلا سيفشل التحقق وسيتعين على العميل الاختيار بين الفشل الجزئي أو الفشل الكامل. لا تنشر العديد من جهات إصدار الشهادات استجابات OCSP مفيدة للشهادات الوسيطة . ^{[ 10 ]}

بما أن الطلبات تُرسل إلى المستجيب استجابةً لتصفح المستخدمين، فإن مستجيبي بروتوكول OCSP يمكنهم معرفة تفاصيل تصفح المستخدمين، وهو ما يُعدّ انتهاكًا للخصوصية . كما يُؤدي ذلك إلى زيادة زمن الاستجابة للاتصالات، إذ يجب الاستعلام من المستجيب قبل استخدام اتصال جديد. ^{[ 19 ]}

وجدت دراسة أجريت عام 2018 أن 1.7% من الطلبات الموجهة إلى المستجيبين كانت غير متاحة على مستوى الشبكة، وأن حوالي 2% أخرى أنتجت استجابات OCSP غير قابلة للاستخدام، مع وجود تباين كبير بين هيئات إصدار الشهادات ووجهات نظر العملاء. ^{[ 33 ]}

يُعدّ OCSP stapling امتدادًا لبروتوكول TLS يوفر إمكانية تقديم استجابات OCSP إلى العميل، بالإضافة إلى الشهادة، عند بدء الاتصال. ^{[ 31 ]}

يمكن لتقنية ربط الشهادات عبر بروتوكول OCSP حل التحديات التشغيلية التي تواجه هذا البروتوكول، وتحديدًا طلبات الشبكة الإضافية التي تُسبب زمن استجابة أعلى وتدهورًا في الخصوصية. ^{[ 34 ]} مع ذلك، قد يكون هذا البروتوكول عرضةً لهجمات خفض مستوى الأمان من قِبل مُهاجم على مسار البيانات. ^{[ 10 ]} يُعرّف RFC 7633 امتدادًا يُضمّن شرطًا في الشهادة ليتم ربطها باستجابة OCSP صالحة. ^{[ 35 ]} مع هذا الامتداد، يُمكن أن يكون الربط فعالًا في حالة اختراق الشهادة بعد إصدارها بشكل صحيح؛ ولكن إذا كان من الممكن إصدار شهادة بشكل خاطئ دون هذا الامتداد، فقد لا يُوفر الربط أي حماية. ^{[ 36 ]}

إلى جانب تمكين العملاء وسلطات المصادقة لتقنية التثبيت (stapling) وامتداد التثبيت الإلزامي، يجب على مديري الخوادم اتخاذ إجراءات لدعم التثبيت من خلال استرجاع الاستجابات بانتظام ثم تقديمها للعملاء أثناء عملية المصافحة. في عام 2018، كان متصفح فايرفوكس هو الوحيد الذي يدعم التثبيت الإلزامي، ولم يدعم أي من خادمي الويب الأكثر استخدامًا ( أباتشي httpd و Nginx ) تثبيت بروتوكول حالة الشهادة عبر الإنترنت (OCSP) على الإطلاق. ^{[ 37 ]}

يستخدم CRLite تمثيلات ثابتة مضغوطة للغاية لحالات الشهادات للعملاء باستخدام مرشحات استعلام العضوية التقريبية ، مما يسمح بالإنتاج والتوزيع والاستعلام بكفاءة. ^{[ 38 ]} يسمح CRLite للعملاء بالتعامل مع الأعطال الصعبة، وبما أن جميع العملاء يسترجعون نفس المعلومات، فلا توجد مخاوف تتعلق بالخصوصية في CRLite. ^{[ 24 ]}

يمكن نشر CRLite بسهولة، ولا يتطلب سوى مُجمِّع لاسترجاع قوائم إبطال الشهادات (CRLs) من هيئات إصدار الشهادات (CAs) ثم توفير سلسلة التصفية وتحديثاتها، واستخدامها من قِبل العملاء؛ ولا يلزم أي إجراء من هيئات إصدار الشهادات، ولا من حاملي الشهادات. ^{[ 24 ]} لا يشترط أن يكون المُجمِّع طرفًا ثالثًا موثوقًا به : إذ يمكن تدقيق سلسلة التصفية للتأكد من أنها تعكس بدقة قوائم إبطال الشهادات المُدخلة. ^{[ 39 ]} كما تتطلب هيئات إصدار الشهادات الخاصة معالجة خاصة ضمن CRLite؛ ^{[ 40 ]} وتشير بيانات من متصفح Firefox إلى أن 5% من الشهادات غير موجودة في سجلات CT، إما بسبب هيئات إصدار الشهادات الخاصة أو بسبب تأخير الدمج. ^{[ 41 ]}

في التصميم الأولي، كان CRLite عبارة عن سلسلة من مرشحات بلوم . ^{[ 38 ]} ينتج عن مرشح واحد مُنشأ من قائمة الشهادات الملغاة نتائج إيجابية خاطئة . مع نطاق مفتوح، تُشكل هذه مشكلة مستعصية على التحقق من الإلغاء. مع ذلك، باستخدام شفافية الشهادات لحصر جميع الشهادات غير المنتهية الصلاحية، يُمكن إنتاج قائمة شاملة بالنتائج الإيجابية الخاطئة. تُستخدم هذه القائمة بعد ذلك لإنشاء مرشح ثانٍ، يُستعان به إذا تطابقت شهادة مع الأول (وبالتالي يكون نطاقه أصغر بكثير)؛ إذا لم يتطابق المرشح الثاني، فهذه نتيجة إيجابية صحيحة وقد تم إلغاء الشهادة؛ مع ذلك، قد يكون التطابق في المرشح الثاني نتيجة سلبية خاطئة، مما يستدعي استخدام مرشح ثالث، وهكذا. بما أن نطاق البحث محدود ونطاق كل مرشح يتناقص بشكل كبير في كل خطوة، فإن هذه العملية تُنتج سلسلة مرشحات محدودة. ^{[ 42 ]}

قُدِّر حجم حالة إبطال جميع الشهادات في البنية التحتية للمفاتيح العامة للويب (Web PKI) في يناير بـ 10 ميجابايت عند استخدام خوارزمية Bloom filter cascade، مع تحديثات يومية بحجم 580 كيلوبايت. وفي مارس 2018، ارتفع هذا الحجم إلى 18 ميجابايت. ^{[ 29 ]} في محاكاة شملت 100 مليون شهادة، ومعدل انتهاء صلاحية يومي بنسبة 1%، ومعدل إبطال بنسبة 2%، تطلّب برنامج CRLite توفيرًا أوليًا قدره 3.1 ميجابايت، ثم 408 كيلوبايت يوميًا للتحديثات. ^{[ 43 ]} وفي تجربة نشر لبرنامج CRLite، وجدت موزيلا في عام 2024 أن معدل التنزيل المُستهلك بلغ 26 ميجابايت على مدى 10 أيام. ^{[ 38 ]}

تم لاحقًا تعديل برنامج CRLite لاستخدام خوارزمية جديدة أكثر كفاءة، أُطلق عليها اسم "بطاقات النادي" ، مما قلل من استهلاك البيانات، وذلك من خلال ملاحظة أن عمليات الإلغاء لا تتوزع بالتساوي بين هيئات إصدار الشهادات (أي أن بعض هيئات إصدار الشهادات لديها معدلات إلغاء أعلى باستمرار من غيرها) ولا عبر الزمن (على سبيل المثال، بسبب أحداث الإلغاء الجماعي)، وأنه من خلال تقسيم الشهادات وفقًا لهذه المعايير، يمكن تحسين الكفاءة. ^{[ 44 ]} بلغ حجم التنزيل الأولي لبيانات اختبار عضوية بطاقات النادي في عام 2024، 7.0 ميجابايت، وشمل 903 ملايين شهادة صالحة و8.7 مليون شهادة ملغاة؛ وكانت التحديثات، التي تُصدر كل ست ساعات، في المتوسط ​​95.5 كيلوبايت، ولكن يمكن ضغطها إلى 26.0 كيلوبايت. مع تقسيم جهة الإصدار فقط، يكون هذا ضمن 12% من الحد الأدنى النظري؛ ومع تقسيم أكثر تطورًا باستخدام تواريخ انتهاء الصلاحية/الإصدار أيضًا، تصل النسبة المتبقية للاستغلال إلى 116%. ^{[ 45 ]}

بعد تجربة نشر تجريبية للتصميم الأولي لـ CRLite في الإصدار 68 من فايرفوكس، ^{[ 38 ]} قامت موزيلا بتطبيق التصميم المُعدَّل في الإصدار 137 من فايرفوكس، وفي أغسطس 2025، عطّلت بروتوكول OCSP للشهادات التي تم التحقق من صحة نطاقها في فايرفوكس 142، ^{[ 7 ]} مما أدى فعليًا إلى الانتقال إلى استخدام CRLite في بيئات الإنتاج. ^{[ 46 ]} في اختبار معملي، وُجد أن فحص الإلغاء يستغرق 10 ميكروثانية فقط لكل شهادة، ومن بيانات ميدانية، انخفض متوسط ​​أوقات مصافحة TLS من 172.4 مللي ثانية إلى 143.4 مللي ثانية، ويعزى ذلك إلى عدم الحاجة إلى استرداد استجابة OCSP. ^{[ 45 ]}

يستخدم Let's Revoke متجهات بت لحالات الإلغاء (تُسمى متجهات إلغاء الشهادات ، أو CRVs) لتمكين العملاء من استرجاع كميات كبيرة من حالات الإلغاء بكفاءة. ^{[ 4 ]} تُنشئ هيئات إصدار الشهادات (CAs) متجهات إلغاء الشهادات لشهاداتها، بمتجه واحد لكل تاريخ انتهاء صلاحية. تكون صيانة متجهات إلغاء الشهادات لهيئات إصدار الشهادات خطيةً مع عدد الشهادات الصادرة. يجب على هيئات إصدار الشهادات إضافة حقل جديد، وهو رقم الإلغاء، إلى كل شهادة صادرة، مما يسمح بتحديد الشهادات الصادرة من هيئة إصدار شهادات واحدة من خلال زوج من تاريخ انتهاء صلاحية الشهادة ورقم الإلغاء؛ يُمكّن هذا الزوج العميل من تحديد بت يُشير إلى حالة الشهادة المُحددة داخل متجه إلغاء الشهادات بكفاءة. يمكن ضغط متجهات إلغاء الشهادات؛ ومن المتوقع أن يكون ضغطها جيدًا جدًا، حيث ستكون معظم البتات غير مُفعّلة في معظم الأوقات. نظرًا لارتباط كل متجه إلغاء شهادات بتاريخ انتهاء صلاحية ثابت، يُمكن التخلص من متجهات إلغاء الشهادات القديمة بكفاءة. تُجمع تحديثات متجهات إلغاء الشهادات في دفعات، مع ختم التحديث زمنيًا وتوقيعه لتوزيعه على العملاء. ^{[ 47 ]} قد تأتي التحديثات في أحد ثلاثة أشكال، ويعتمد الاختيار الأمثل على معدل الإلغاء، مما يسمح بكل من التشغيل العادي الفعال وأحداث الإلغاء الجماعي. ^{[ 48 ]}

من المتوقع أن تكون سجلات التحقق من صحة الشهادات (CRVs) صغيرة بما يكفي لتمكين التحقق القائم على الدفع، ولكن قد يلجأ العملاء ذوو الموارد المحدودة إلى التحقق القائم على السحب، حيث يقتصر وصولهم على سجلات CRVs محددة، أو يؤجلون استرجاعها حتى التحقق من صحة الشهادة. ^{[ 49 ]} يستطيع العميل الذي يستخدم Let's Revoke مع التحقق القائم على الدفع أن يفشل بشكل قاطع لأي شهادة تحمل رقم إبطال. ^{[ 24 ]} يعتمد تأثير Let's Revoke على الخصوصية وتوافره على بنية النظام: فإذا كانت جميع عمليات التحقق قائمة على الدفع، فلن يكون هناك تسريب للخصوصية، وسيقل احتمال التعرض لهجمات حجب الخدمة أو انقطاع الخدمة؛ أما إذا تم استخدام عمليات التحقق القائمة على السحب، فسيتم تسريب بعض المعلومات حول أنشطة المستخدم (مثل سجلات CRVs التي يتم الوصول إليها)، وقد لا يكون الوصول إلى سجلات CRVs ممكنًا وقت التحقق. ^{[ 24 ]}

في محاكاة شملت 100 مليون شهادة، ومعدل انتهاء صلاحية يومي بنسبة 1%، ومعدل إلغاء بنسبة 2%، تطلبت خدمة Let's Revoke توفيرًا أوليًا قدره 2.2 ميجابايت، ثم 114 كيلوبايت يوميًا للتحديثات. ^{[ 50 ]}

لم يُعمَّم تطبيق Let's Revoke على نطاق واسع بعد. ^{[ 10 ]} فإلى جانب تطبيقات العملاء، يتطلب من هيئات إصدار الشهادات إجراء تغييرات تشغيلية، ^{[ 51 ]} ولا يوفر معلومات كافية مثل قوائم إبطال الشهادات (CRLs) أو بروتوكول حالة الشهادة عبر الإنترنت (OCSP) (بت واحد فقط لكل شهادة للتحقق من صحتها)؛ ومع ذلك، يمكن استخدام قوائم إبطال الشهادات أو بروتوكول حالة الشهادة عبر الإنترنت لتكملة Let's Revoke وتوفير تلك المعلومات الإضافية. ^{[ 52 ]} ويمكن تنفيذ النشر من قِبل هيئة إصدار شهادات تلو الأخرى، مع استفادة العملاء من خاصية التحقق من صحة الشهادات بشكل تدريجي. ونظرًا لكفاءة التحقق من صحة الشهادات مقارنةً بقوائم إبطال الشهادات واستجابات بروتوكول حالة الشهادة عبر الإنترنت، فقد تُشجَّع هيئات إصدار الشهادات على نشر Let's Revoke. ^{[ 51 ]}

يمكن لتقنيات استرجاع المعلومات الخاصة أن تُخفف من مخاوف الخصوصية من خلال عمليات التحقق القائمة على السحب. ^{[ 53 ]} وبدلاً من قيام العملاء بإجراء عمليات التحقق من الإلغاء، يمكن لجهاز وسيط أن يقوم بذلك، مركزيًا تكلفة التحقق من الإلغاء وموزعًا إياها على العديد من الاتصالات؛ ولا يحتاج العملاء إلى تخصيص أي مساحة تخزين لمعلومات الإلغاء. ^{[ 54 ]} وتضمن اقتراح آخر بث معلومات الإلغاء على راديو FM . ^{[ 42 ]}