الخلاصة

  • سمح OCSP stapling بوصول استجابة موقّعة عن حالة الشهادة ضمن تبادل TLS. صار الخادم ناقلاً لها، من دون أن يكتسب سلطة توقيعها أو أن يحل محل العميل في التحقق منها.
  • خفّضت إعادة الاستخدام الحاجة إلى استعلام خارجي، لكنها استلزمت ضبط عمر الاستجابة وتحديثها. ويمكن لإعلان الوظيفة داخل الشهادة أن يجعل غيابها ذا دلالة، مع ربط تشغيل الشهادة الجديدة بجاهزية دليل حالتها.

اتصال لم يعد ضرورياً

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

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

فخدمة الحالة لا تختفي. لا يزال على جهة ما إنتاج استجابات جديدة، وعلى الخادم الحصول عليها وتقديم الاستجابة المناسبة للشهادة المناسبة. ما اختفى من مسار الزائر بقي عملاً دورياً في تشغيل الموقع.

كيف ينقل الطرف الخاضع للفحص دليله؟

تبدو المفارقة واضحة: الخادم يقدّم شهادة يريد من العميل قبولها، ثم يقدّم أيضاً إفادة عن حالتها. لو كانت الإفادة مجرد كلام صادر عن الخادم لكانت العملية تزكية ذاتية.

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

وكلمة good أضيق من معناها اللغوي الظاهر. لا يثبت هذا الرد بالضرورة أن الشهادة قد صدرت أصلاً، ولا أنه حكم على أمان الموقع. كما لا يستبدل فحص سلسلة الشهادات وسائر شروط القبول.

هكذا يمكن نقل دليل عبر طرف له مصلحة في النتيجة، من دون جعله المرجع الذي يقرر مضمون الدليل. إنتاج الإفادة وتسليمها وقبولها ثلاثة أفعال منفصلة، حتى حين تنفّذ مؤسسة واحدة أكثر من دور.

قبل مراجعة 2011 بثمانية أعوام

وصف RFC 3546 في يونيو 2003 طلب الحالة عبر status_request وإمكان إرسال استجابة OCSP بعد الشهادة. شملت دوافعه توفير موارد الشبكات المقيدة وتقليل نقل قوائم الإلغاء والذهاب والإياب الإضافي.

ثم أعاد RFC 6066 في يناير 2011 وصف الامتداد ضمن إطار TLS اللاحق. كانت رسالة مستقلة باسم CertificateStatus تحمل الاستجابة المرمّزة كاملة. لم يكن تبادل TLS يصنع إفادة جديدة من عنده، ولم تكن مراجعة 2011 نقطة اختراع الآلية.

والتمييز بين وصف المعيار وانتشاره مهم هنا. وثيقة البروتوكول تثبت ما أتاحه التصميم، لا عدد المواقع أو العملاء الذين طبقوه فعلياً في سنة معينة.

دليل محفوظ لا يعني حالة آنية

تسمح الاستجابة المعدّة مسبقاً بتوزيع الجواب نفسه على أكثر من استخدام. عالج الملف الخفيف في RFC 5019، الصادر في سبتمبر 2007، الإنتاج المسبق والتوزيع والتخزين المؤقت بوصفها أدوات للتوسع.

غير أن التوقيع الصحيح قد يرافق معلومة قديمة. يشير thisUpdate إلى الوقت الذي كانت فيه الحالة المعلنة معروفة بأنها صحيحة، وproducedAt إلى وقت التوقيع، وnextUpdate إلى الموعد الذي ستتاح عنده معلومات أحدث أو قبله. توقيع ملاحظة قديمة في وقت لاحق لا يجعل الملاحظة حديثة.

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

يمكن لاستجابة محفوظة ومقبولة أن تمنح المشغّل هامشاً أثناء تعطل خدمة الحالة. لكن الهامش ينتهي عندما لا تعود الاستجابة مستوفية لقواعد العميل. وإعلان إلغاء جديد لا يعيد كتابة جميع نسخ الرد الإيجابي السابق التي وُزعت بالفعل. إعادة الاستخدام توفر العمل لأنها تقبل فاصلًا زمنياً بين معرفة الحالة والاستناد إليها، لا لأنها تلغي ذلك الفاصل.

الغياب ليس إعلان إلغاء

كانت الآلية الأصلية اختيارية. طلب العميل لا يضمن أن يرفق الخادم الاستجابة. وقد يعني غيابها أن الخادم لا يدعم الوظيفة، أو أنه لا يريد تقديم معلومة غير ملائمة له.

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

في أكتوبر 2015، قدّم RFC 7633 امتداد X.509 المسمى TLS Feature. يمكن للشهادة أن تعلن فيه status_request، وهو أساس ما يُعرف عادة باسم Must-Staple. عندئذ يستطيع العميل الداعم مقارنة تصرف الخادم بتوقع موثّق داخل الشهادة، بدل الاكتفاء بتفسير الخادم لغياب الدليل.

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

تغيّر الوعاء وبقيت الصلاحية منفصلة

في RFC 8446 لعام 2018، وضع TLS 1.3 معلومات الحالة داخل امتداد في CertificateEntry المرتبط بالشهادة، بدلاً من الرسالة المستقلة القديمة. تغيير موضع الحمل لم يجعل الخادم جهة توقيع مخوّلة، ولم يلغ فحص الوقت.

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

المصادر

RFC 3546، RFC 6066، RFC 6960، RFC 5019، RFC 7633، وRFC 8446. تحليل توزيع التكلفة والمسؤولية مستنتج من المتطلبات، وليس ادعاءً بقياس الانتشار الفعلي.