موعد إلغاء شهادات DigiCert حول التحقق من صحة الشهادات إلى اختبار مساءلة عن وقت التشغيل

الملخص

• أبلغت DigiCert في Mozilla Bugzilla أنها تحققت من بعض النطاقات باستخدام قيمة عشوائية في سجل CNAME بدون البادئة المسطرة السفلية المطلوبة، مما أثر على مسار في نظام التحقق من OEM الخاص بها. ذكر تقرير الحادثة أن 83,267 شهادة TLS صالحة صدرت بناءً على هذه الطريقة، وأن المجموعة المتأثرة قد تكون مبالغًا في تقديرها لأن النظام لم يخزن بشكل كافٍ ما إذا كانت المسطرة السفلية موجودة.
• كانت مشكلة الإلغاء فورية. تتطلب متطلبات TLS الأساسية من CA/Browser Forum الإلغاء ضمن أطر زمنية محددة للشهادات الصادرة بشكل غير صحيح، ويذكر تقرير حادثة الإلغاء المؤجل من DigiCert أنها ألغت جميع الشهادات البالغ عددها 83,267 المتأثرة في غضون 120 ساعة بدلاً من فترة 24 ساعة المطلوبة بموجب القواعد السارية آنذاك.
• لم يكن الحدث مجرد خطأ في برمجة CA. لقد كشف عن ضعف في جرد الشهادات بين المشتركين، وقيود التواصل عبر الموزعين والحسابات المؤسسية، والضغوط القانونية من نزاع على أمر قضائي مؤقت من عميل، وحقيقة أن العديد من المنظمات ما زالت تفتقر إلى الأتمتة لاستبدال الشهادات بسرعة على نطاق واسع.
• كان التحكم العملي موزعًا. سيطرت DigiCert على تنفيذ التحقق، وتحديد الشهادات، وإخطار العملاء، وتنفيذ الإلغاء، وإعداد تقارير الحوادث. سيطرت برامج الجذر ومنتدى CA/Browser على توقعات الثقة والضغط السياسي، ولكن ليس على نشر العملاء. سيطر المشتركون على جردهم، وأتمتتهم، ونوافذ التغيير، ونشر الخدمات المحدد. لم يتحكم المستخدمون النهائيون في أي شيء تقريبًا من المخاطر.
• الدرس في المساءلة هو أن سلطات الشهادات لا يمكنها التعامل مع الإلغاء كحدث ورقي نادر، ولا يمكن للمشتركين التعامل مع شهادات TLS الموثوقة علنًا كبنية تحتية ثابتة. يعتمد نموذج الأمان لـ Web PKI على أن الاستبدال السريع يكون مملًا من الناحية التشغيلية قبل وصول الطوارئ.

مسطرة سفلية مفقودة أصبحت مشكلة استمرارية عالمية

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

سجل الحادثة العام لـ DigiCert في Mozilla Bugzilla bug 1910322 هو المرجع الوقائعي. أبلغت DigiCert أنها تلقت تقرير مشكلة شهادة يشير إلى احتمال وجود مشكلة في تنفيذ الطريقة 7، التحقق المستند إلى DNS. وصفت عمليات تحقق متعددة متعلقة بـ DNS وقالت إن مراجعة الكود وجدت مسارًا واحدًا يمكن أن تصدر فيه شهادة عندما تُستخدم القيمة العشوائية كمضيف في سجل CNAME دون إضافة مسطرة سفلية أولاً. في وقت لاحق من نفس الخطأ، قال تقرير حادثة DigiCert إن التأثير كان محدودًا على المصدرين الذين يستخدمون نظام التحقق من OEM الخاص بها، بينما كانت مسارات التحقق عبر CertCentral وCIS، محرك الإصدار عالي الحجم لمزودي الخدمات السحابية، تتحقق من النطاقات بشكل صحيح ولم تتأثر.

الرقم أيضًا من سجل الحادثة العام. قالت DigiCert إن 83,267 شهادة صالحة صدرت بناءً على الطريقة وأنها ستلغي جميع الشهادات الصالحة في قاعدة البيانات المدرجة على أنها تستخدم التحقق المستند إلى DNS CNAME قبل تاريخ الإصلاح. وأوضحت أن هذا ربما بالغ في تقدير المجموعة المتأثرة الحقيقية لأن ضوابط نظام OEM لم تخزن بشكل كافٍ ما إذا كانت المسطرة السفلية موجودة. هذه الجملة هي مفصل المساءلة. يمكن للنظام تحديد مجموعة مخاطر، ولكن لا يمكنه إثبات أي الشهادات كانت بالشكل المطابق. في نظام الثقة، يمكن أن يصبح عدم اليقين بشأن الامتثال التزامًا بالإلغاء.

السبب الأمني للمسطرة السفلية ليس جماليًا فقط. تميز طرق التحقق من CA/Browser Forum بين الأسماء التي يتحكم بها المشترك والأسماء التي قد تكون مفوضة أو منشأة من قبل المستخدم تحت نطاق أكبر. ركزت المناقشة في Bugzilla على أن التسمية المسبوقة بمسطرة سفلية تساعد في إنشاء فضاء تحقق خاص يمكن لأسماء المضيفين العادية والعديد من خدمات النطاق الفرعي المفوضة تجنبه. يمكن أن تقوض المسطرة السفلية المفقودة افتراضًا يستخدم لمنع إصدار الشهادات غير المرغوب فيها حيث يمكن للمستخدمين إنشاء نطاقات فرعية تحت نطاق لا يتحكمون به.

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

القواعد فعلت ما تفعله القواعد: فرضت العمل

متطلبات TLS الأساسية من CA/Browser Forum هي مجموعة القواعد العامة في مركز الحادثة. تحدد طرق التحقق من النطاق والتزامات إلغاء الشهادات لشهادات خادم TLS الموثوقة علنًا. لا تحتاج المقالة إلى اقتباس كل شرط لشرح هيكل المساءلة: إذا صدرت شهادة بشكل غير صحيح أو لم يتوافق التحقق مع المتطلبات الأساسية، يجب على CA الإلغاء ضمن الموعد النهائي المطبق ما لم تسمح القواعد نفسها بمسار آخر.

يذكر تقرير الإلغاء المؤجل لـ DigiCert في Mozilla Bugzilla bug 1910805 تعارض الامتثال بوضوح. قالت DigiCert إنها عملت على إلغاء جميع الشهادات خلال 24 ساعة، ولكن بعد المناقشة مع برامج الجذر والمجتمع حول التأثير، قررت التأخير وإلغاء جميع الشهادات المتأثرة خلال 120 ساعة. لخص تقرير حادثتها اللاحق التأثير: ألغت DigiCert 83,267 شهادة في خمسة أيام بدلاً من 24 ساعة كما هو مطلوب في المتطلبات الأساسية الحالية.

هذا الاعتراف مهم لأنه يفصل بين حادثتين. تعلق bug 1910322 بعدم الامتثال للتحقق من النطاق. تعلق bug 1910805 بالإلغاء المؤجل. المشكلة الأولى كانت كيف أصبحت الشهادات تعتبر غير متوافقة. المشكلة الثانية كانت كيف تعامل النظام البيئي مع التزام إزالة تلك الشهادات من الثقة بينما كان العملاء لا يزالون يعتمدون عليها في الخدمات الحية.

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

كانت برامج الجذر حذرة بشأن السلطة. في سلسلة Bugzilla، قال ممثلو برنامج Chrome Root Program إنهم لا يملكون سلطة منح استثناءات لمتطلبات TLS الأساسية من CA/Browser Forum وأن هذه المتطلبات مدفوعة بالإجماع وليست مملوكة لبرنامج جذر واحد. توفر سياسة برنامج جذر Chrome السياق الأوسع لمتصفح الجذر: تشارك CA في متجر الجذر تحت توقعات البرنامج وتقييم الحوادث وضغط الامتثال المستمر. لكن استشارة برنامج الجذر أثناء الأزمة ليست إعفاءً سحريًا من القواعد العامة.

تخدم سياسة متجر جذر Mozilla وإرشادات استجابة الحوادث لـ CA من Mozilla وظيفة مماثلة. تجعل الإبلاغ عن الحوادث والاستجابة جزءًا من حوكمة الثقة. لا تشغل خوادم المشتركين، ولا تجرد الشهادات داخل البنية التحتية للعملاء. إنها تنشئ منتدى المساءلة العام الذي كان على DigiCert فيه شرح ما حدث وما سيتغير.

كان تقرير DigiCert صريحًا بشكل غير معتاد حول الأسباب التنظيمية

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

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

يتضمن نفس سجل Bugzilla قيادة DigiCert تعترف بأن الفرق الداخلية لم تعمل دائمًا معًا كما ينبغي وأن العالم الذي يعتمد عليها جعل ذلك غير مقبول. هذا ليس حكمًا قانونيًا، لكنه اعتراف مؤسسي قوي: سلطة الشهادات الموثوقة علنًا ليست مجرد بائع SaaS آخر. كود التحقق الخاص بها يقدم ادعاءات تعتمد عليها المتصفحات وأنظمة التشغيل ومواقع الويب والوكالات والبنوك والمستشفيات والمستخدمون دون رؤية سير العمل الداخلي لـ CA.

قالت DigiCert أيضًا أن المسار المتأثر كان محدودًا بنظام التحقق من OEM، وليس CertCentral وCIS. هذه الحدود مهمة. تمنع المبالغة في تقدير الحادثة كفشل لكل قنوات التحقق من DigiCert. لكن الحدود تثير أيضًا سؤال تحكم: لماذا كان لمسار نظام تحقق واحد سلوك امتثال مختلف، ولماذا لم يحتفظ نموذج البيانات بتفاصيل كافية للتمييز بين الحالات المطابقة وغير المطابقة بعد وقوع الحدث؟

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

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

الجانب المشترك حوّل السياسة إلى ألم

قال تحديث Bugzilla الأولي لـ DigiCert إن 83,267 شهادة تأثر بها 6,807 مشترك. كما قال إن العديد من العملاء الذين يديرون بنية تحتية حيوية وشبكات اتصالات حيوية وخدمات سحابية وصناعات رعاية صحية لم يكونوا في وضع يسمح بإلغاء شهاداتهم دون انقطاعات خدمات حيوية. لم يكن هذا البيان إعفاءً شاملاً. كان دليلاً على أن أجزاء كبيرة من النظام البيئي للمشتركين كانت غير مستعدة تشغيليًا للاستبدال السريع.

يظهر تنبيه إلغاء شهادات DigiCert من CISA تأثير الخدمة العامة. قالت CISA إن DigiCert كانت تلغي مجموعة فرعية من شهادات TLS بسبب مشكلة عدم الامتثال في التحقق من صحة النطاق، وحذرت من أن الإلغاء قد يسبب اضطرابات مؤقتة لمواقع الويب والخدمات والتطبيقات التي تعتمد على تلك الشهادات للاتصال الآمن. حثت CISA العملاء على التحقق من حساب DigiCert الخاص بهم وإعادة إصدار أو إعادة مفتاح الشهادات. أشار تحديث 31 يوليو العملاء إلى معلومات ومواعيد نهائية محدثة وشجعت على الاتصال بـ DigiCert إذا لم يتمكنوا من إعادة الإصدار أو إعادة المفتاح بحلول الموعد النهائي المحدث للإلغاء.

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

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

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

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

الموزعون وقنوات العملاء كانوا جزءًا من سطح الفشل

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

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

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

خدم إشعار حادثة الإلغاء من DigiCert، المرتبط من CISA وفي مناقشة Mozilla، دور الإشعار الموجه للعملاء. كما تمت الإشارة إلى بوابة حالة DigiCert على status.digicert.com من قبل CISA للجداول الزمنية المحدثة. تلك الصفحات مهمة حتى عندما يكون الوصول الأرشيفي غير كامل لأن الوكالات العامة ومناقشات برنامج الجذر أشارت العملاء إليها أثناء الحادثة.

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

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

الضغط القانوني كشف الحافة الضعيفة للإلغاء الإلزامي

يقول تقرير الإلغاء المؤجل إن DigiCert تلقت إشعارًا بأن عميلًا قدم طلبًا لأمر قضائي مؤقت ضد الإلغاء. الملف العام، Alegeus Technologies LLC v. DigiCert، جزء من سجل الحادثة لأنه يوضح كيف يمكن أن يتعارض ضغط استمرارية المشترك مع التزامات CA. قالت تعليقات Bugzilla اللاحقة إن القضايا القانونية تم حلها بين الطرفين.

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

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

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

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

الأتمتة كانت طبقة المرونة المفقودة

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

تم إنشاء ACME، المحددة في RFC 8555، لأتمتة إصدار الشهادات وإدارتها. الأتمتة ليست مقتصرة على ACME، وليس كل نظام مؤسسي جاهز لـ ACME. لكن المبدأ أوسع: يجب أن تكون الشهادات قابلة للتجديد والاستبدال من خلال سير عمل مُختبر، وليس طقوسًا يدوية مرة في السنة. يُظهر اقتراع SC-063 من CA/Browser Forum بشأن الشهادات قصيرة العمر وحوافز الأتمتة أن الصناعة كانت تدفع بالفعل نحو أعمار أقصر وخفة حركة أفضل قبل هذه الحادثة.

قدمت تعليقات برنامج Chrome Root Program في Bugzilla نفس النقطة. قال ممثلو Chrome إنهم يعطون الأولوية لتحسين خفة الحركة والمرونة عبر Web PKI بحيث تكون أحداث الإلغاء أقل اضطرابًا، وأشاروا إلى أن الأتمتة ونهج ARI لها فائدة محدودة بدون اعتماد واسع من قبل CAs والمشتركين. مسودة تمديد معلومات تجديد ACME ذات صلة لأنها تهدف إلى السماح لـ CAs بإرسال معلومات توقيت التجديد لعملاء ACME. إنها ليست حلاً كاملاً لجميع مشاكل الإلغاء المؤجل، لكنها تعكس الاتجاه الصحيح: تنسيق التجديد والاستبدال المقروء آليًا.

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

بالنسبة لـ CAs، يجب أن تتضمن الأتمتة اكتشاف الشهادات المتأثرة وإخطار العملاء. في Bugzilla، أشارت مناقشة DigiCert إلى أن جمع معلومات الشهادة والاتصال تضمن بحيرة بيانات مركزية وفريق ذكاء الأعمال. هذا التفصيل يجب أن يقلق أي CA. إذا كان فريق خارج الاستجابة العادية للحوادث مطلوبًا لتجميع قائمة خلال موعد نهائي مدته 24 ساعة، فإن العملية ليست تشغيلية بما فيه الكفاية. يجب أن تكون البيانات اللازمة للإلغاء جاهزة للحوادث.

الأتمتة ليست وسيلة لتجنب المساءلة. إنها الوسيلة التي تصبح بها المساءلة ممكنة على نطاق الإنترنت. القواعد التي تطلب الإلغاء السريع ليست ذات مصداقية إلا إذا تمكنت CAs والمشتركون من تنفيذ الاستبدال السريع دون جهد يدوي بطولي في كل مرة.

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

يمكن أن يؤدي فقدان أي من هذه الخطوات إلى تحويل تصحيح الامتثال لـ CA إلى توقف دائم للعملاء.

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

الشهادات المتأثرة كانت مشكلة ثقة، وليس بالضرورة نتيجة استغلال

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

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

يوفر الموقع العام لـ CCADB سياقًا للبنية التحتية للشفافية المستخدمة من قبل متاجر الجذر و CAs، بينما تساعد crt.sh وسجلات شفافية الشهادات المجتمع في فحص الشهادات الصادرة. في سلسلة Bugzilla، حلل أعضاء المجتمع قوائم الشهادات المقدمة من DigiCert مقابل بيانات شفافية الشهادات. هذه قوة في Web PKI: الأدلة العامة موجودة للمراجعة الخارجية. إنها أيضًا تذكير بأن الشفافية بعد الإصدار لا تحل محل التحقق الصحيح قبل الإصدار.

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

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

برامج الجذر كانت مشرفين، وليس مشغلي وقت تشغيل العملاء

تشكل برامج جذر Mozilla و Chrome و Apple و Microsoft النظام البيئي لـ CA الموثوق علنًا. سياسة متجر جذر Mozilla، سياسة برنامج جذر Chrome، معلومات شفافية الشهادات وبرنامج الشهادات الموثوقة من Apple، متطلبات برنامج الجذر الموثوق من Microsoft كلها تساعد في تحديد بيئة الثقة التي تعمل فيها CAs. تختلف السياسات المحددة، لكن الفكرة المشتركة هي أن تضمين متجر الجذر مشروط بسلوك CA الجدير بالثقة.

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

هذا لا يجعل برامج الجذر سلبية. كانت تعليقاتها العامة في Bugzilla مهمة لأنها قاومت صنع الاستثناءات الخاصة وحافظت على الضغط على المتطلبات الأساسية. تعليق Chrome بأنه يفتقر إلى سلطة منح الاستثناءات هو بيان مساءلة. أظهرت مناقشة Mozilla اللاحقة لمراجعة سياسة الإلغاء المؤجل أن الحادثة يمكن أن تغذي حوكمة برنامج الجذر. منتديات برنامج الجذر العامة هي حيث تصبح تفسيرات CA قابلة للمراجعة من قبل أكثر من العميل المتأثر وCA.

منتدى CA/Browser Forum هو طبقة أخرى. يكتب المنتدى المتطلبات الأساسية من خلال الإجماع بين CAs والمتصفحات. صفحة متطلبات TLS الأساسية ليست إذن قانونًا خارجيًا مفروضًا على DigiCert وحدها. تشارك DigiCert و CAs أخرى في النظام البيئي الذي يخلق الالتزامات. عندما تجد CA لاحقًا الالتزام مؤلمًا تشغيليًا، فهذه إشارة لتحسين خفة الحركة في النظام البيئي، وليس دليلاً على أن الالتزام تعسفي.

أصعب سؤال حوكمة هو ما إذا كان يجب أن تكون الجداول الزمنية للإلغاء أكثر مرونة لعدم الامتثال منخفض الشدة ومخاطر التوفر العالية. يختلف الأشخاص المعقولون في مجتمع Web PKI. لا تحل هذه المقالة هذا النقاش السياسي. إنها تحدد حقيقة المساءلة: في وقت الحادثة، اعترفت DigiCert بمتطلبات 24 ساعة ثم أكملت الإلغاء على مدار 120 ساعة. هذا التباين هو حدث ثقة عامة.

ما سيطرت عليه DigiCert وما سيطر عليه المشتركون

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

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

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

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

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

أدلة وضوابط أفضل للحادثة التالية

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

نشر DigiCert لاحقًا كود التحقق من صحة النطاق على github.com/digicert/domain-control-validation، مع معلومات الحزمة مرئية على Maven Central والوثائق على javadoc.io، ذو صلة هنا. يمكن أن تساعد مواد التنفيذ المفتوحة العملاء والمجتمع على فهم سلوك التحقق، على الرغم من أن الكود المفتوح وحده لا يثبت التكوين الإنتاجي أو يزيل المخاطر التنظيمية.

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

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

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

خامسًا، يجب على برامج الجذر ومنتدى CA/Browser Forum مواصلة المناقشة العامة حول الإلغاء المؤجل دون السماح لثقافة الاستثناء الخاص بأن تصبح طبيعية. إذا تطورت القواعد، يجب أن تتطور بشفافية. إذا لم تتطور، يجب على CAs والمشتركين بناء عمليات للوفاء بها.

الدرس الدائم

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

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

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

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