إرث Sectigo من Comodo يُظهر كيف يمكن للثقة بالشهادات أن تفشل عبر الإصدار المفوض

ملخص

• سجل عام مؤكد:ذكر تقرير حادثة Comodo أنه في 15 مارس 2011، تم اختراق حساب سلطة تسجيل واستُخدم لإصدار تسع شهادات احتيالية عبر سبعة نطاقات؛ كما ذكر أنه تم إبطال جميع الشهادات فور اكتشافها وأن مراقبة حركة استجابة OCSP لم ترصد أي محاولة استخدام بعد الإبطال. (تقرير حادثة Comodo)
• استجابة المتصفحات والمنصات:تعاملت Mozilla وMicrosoft وغيرها من مشغلي المتصفحات والمنصات مع الحدث على أنه أكثر من مجرد مسألة تنظيف داخلية للمُصدر. أصدرت Mozilla تحديثًا لقائمة حظر الشهادات، وأصدرت Microsoft الاستشارية الأمنية 2524375 وتحديثًا وضع الشهادات التسع في مخزن الشهادات غير الموثوقة في Windows، ووصفت متابعة Mozilla مسار سلطة التسجيل المخترق. (استشارية Mozilla،استشارية Microsoft،متابعة Mozilla)
• حدود المساءلة:تدعم الأدلة العامة فشل الإصدار المفوض، وليس دليلاً عاماً على أن مفاتيح Comodo الجذرية أو وحدات الأمن المادي (HSM) قد اخترقت. قالت Comodo إن بنيتها التحتية للـ CA ومفاتيح HSM لم تخترق. هذا التمييز يضيق المطالبة التقنية، لكنه لا يضيق مشكلة المساءلة: الحساب المفوض ما زال ينتج شهادات موثوقة من المتصفحات لنطاقات عالية القيمة.
• التقييم:كان المهاجم مسؤولاً عن الاختراق ومحاولة إساءة الاستخدام. كانت Comodo تتحكم في نموذج الإصدار المفوض، ومصادقة الموزعين، وضوابط ما بعد الحادثة؛ وبائعو المتصفحات ونظم التشغيل تحكموا في عدم الثقة الطارئ؛ برامج الجذور تحكمت في الثقة المستمرة؛ والخدمات المعتمدة على الأطراف والمستخدمون تحملوا عواقب لم يستطيعوا ملاحظتها مباشرة.

يمكن لسلطة الشهادات أن تفشل بعيدًا عن المفتاح الجذري

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

هذا الفرق مهم. اختراق المفتاح الجذري يطرح سؤالاً عما إذا كانت المرساة التشفيرية الأساسية لا تزال قابلة للاستخدام. اختراق الإصدار المفوض يطرح سؤالاً تشغيليًا أصعب: كم من صلاحية سلطة الشهادات العملية توضع في حسابات الشركاء، وسير عمل الموزعين، وموظفي التحقق، والأنظمة المؤتمتة، وقنوات الإبطال الطارئة؟ إذا كان حساب مفوض يمكنه أن يتسبب في إصدار شهادات لـ mail.google.com، وwww.google.com، و login.yahoo.com، و login.skype.com، و addons.mozilla.org، و login.live.com، فإن نظام الثقة لم يفشل عند الجذر الرياضي. لقد فشل عند الحافة الإدارية.

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

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

الأسماء بحد ذاتها تحمل المشكلة. شهادة لنقطة نهاية تسجيل دخول ليست قطعة أثرية تزيينية. إنها اعتماد لتقديم هوية تشفيرية للمتصفحات. إذا تمكن مهاجم من دمج مثل هذه الشهادة مع إعادة توجيه حركة المرور، أو التلاعب بـ DNS، أو التحكم في الشبكة المحلية، أو التداخل في التوجيه، أو البرمجيات الخبيثة، أو الوصول إلى الشبكة على مستوى الدولة، فقد لا يكون لدى المستخدم وسيلة اعتيادية لرؤية أن الاتصال ليس مع الخدمة المقصودة. حذرت Microsoft من أن الشهادات يمكن استخدامها لانتحال المحتوى، أو تنفيذ هجمات تصيد، أو تنفيذ هجمات رجل في الوسط ضد مستخدمي المتصفح. (استشارية Microsoft 2524375)

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

التسلسل الزمني العام ملموس بشكل غير معتاد

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

ربطت متابعة Mozilla فشل الحساب هذا بثقة المتصفح. قالت Mozilla إن شريك سلطة تسجيل تابع لـ Comodo تعرض لخرق أمني داخلي، وأن المهاجم استخدم حساب سلطة التسجيل لدى Comodo للتسبب في إصدار تسع شهادات احتيالية. أشارت Mozilla أيضًا إلى أن الشهادات أُبطلت، وأن Firefox أصدر تحديثات لإضافتها إلى القائمة السوداء، وأن Mozilla كانت تناقش إجراءات أخرى مع Comodo وسلطات شهادات أخرى. (متابعة Mozilla)

استشارية مؤسسة Mozilla الأمنية 2011-11 موجزة لكنها مهمة. أعلنت عن تحديث لقائمة حظر شهادات HTTPS في 22 مارس 2011، بتأثير مرتفع، يؤثر على Firefox وSeaMonkey، ووصفت وضع عدة شهادات HTTPS غير صالحة على القائمة السوداء لمنع إساءة الاستخدام. سجل Bugzilla الخاص بأعمال الحظر هو أثر عام لاستجابة جانب المتصفح. (MFSA 2011-11،Mozilla Bugzilla 642395)

أضافت استشارية Microsoft الأمنية 2524375 طبقة منصة. قالت Microsoft إن Comodo أبلغتها في 16 مارس 2011 بأنه تم توقيع تسع شهادات نيابة عن طرف ثالث دون التحقق الكافي من هويته. أدرجت Microsoft الخصائص المتأثرة، ووصفت مخاطر الانتحال والتصيد وهجمات رجل في الوسط، وقالت إن Comodo أبطلت الشهادات وأدرجتها في قائمة إبطال الشهادات الخاصة بها. ومع ذلك، أصدرت Microsoft تحديثات لوضع الشهادات التسع في مخزن الشهادات غير الموثوقة المحلي لأن عمليات التحقق من الإبطال لم تكن قوية بما يكفي لضمان الحماية في جميع ظروف الشبكة. (استشارية Microsoft 2524375)

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

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

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

التفويض ليس ثغرة في المسؤولية

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

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

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

تتحدث القواعد الأساسية الحديثة وسياسات مخازن الجذور عن هذه القضايا بشكل أكثر وضوحًا مما كان عليه النظام البيئي في عام 2011. توفر المتطلبات الأساسية لمنتدى CA/Browser الآن متطلبات عامة لإصدار شهادات الخادم، والتحقق، والإبطال، وعمليات سلطات الشهادات. تحدد سياسة مخزن جذور Mozilla ومواد الإنفاذ شروط تضمين وتأديب سلطات الشهادات الموثوقة من منتجات Mozilla. (المتطلبات الأساسية لمنتدى CA/Browser،سياسة مخزن جذور Mozilla،سياسة إنفاذ Mozilla للسلطات المصدّرة)

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

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

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

نجح الإبطال، لكن ليس بما يكفي لإنهاء المشكلة

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

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

تساعد المعايير الأساسية في تفسير الهيكل. يعرّف RFC 5280 ملف تعريف شهادة X.509 للبنية التحتية للمفتاح العام على الإنترنت وملف تعريف CRL، بينما يعرّف RFC 6960 OCSP كوسيلة للعملاء للحصول على معلومات حالة الشهادة. تخلق هذه الأدوات مفردات عامة للإصدار والإبطال، لكنها لا تضمن أن كل مستخدم، ومتصفح، وجهاز، وشبكة، وتطبيق يفرض نفس سلوك الفشل في نفس اللحظة. (RFC 5280،RFC 6960)

هذه الفجوة في الإنفاذ هي سبب أهمية القوائم السوداء للمتصفحات. وضع تحديث Mozilla شهادات HTTPS غير الصالحة على قائمة سوداء لمنع إساءة الاستخدام. القائمة السوداء للمتصفح أداة غير دقيقة، لكنها حاسمة. إنها تزيل الاعتماد على اتصال شبكة قد يمنعه المهاجم أو يعترضه أو يجعله يفشل. التكلفة هي أن البائعين يجب أن يشحنوا والمستخدمين يجب أن يتلقوا التحديثات بسرعة كافية لتكون ذات أهمية. (MFSA 2011-11)

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

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

يعطي التطور اللاحق لشفافية الشهادات الدرس إطارًا آخر. وصف RFC 6962 تصميم تسجيل عام تجريبي للشهادات، وحدد RFC 9162 لاحقًا الإصدار 2 من شفافية الشهادات. تعكس سياسة شفافية الشهادات من Google لمتصفح Chrome فكرة أن الشهادات المسجلة علنًا أسهل في الاكتشاف والتدقيق. (RFC 6962،RFC 9162،سياسة شفافية الشهادات في Chrome)

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

ثقة مخزن الجذور هي منفعة عامة تديرها برامج خاصة

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

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

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

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

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

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

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

ورثت Sectigo أكثر من مجرد اسم علامة تجارية

موضوع المقال هو Sectigo لأن الكيان الحالي هو العلامة التجارية الخلف لأعمال سلطة الشهادات Comodo. تصف مواد Sectigo العامة تغيير العلامة التجارية لـ Comodo CA وأعمال دورة حياة الشهادات والثقة الرقمية. (Comodo CA أصبحت الآن Sectigo،صفحة حول Sectigo)

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

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

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

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

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

النطاقات عالية القيمة تكشف الاقتصاد السياسي للإساءة

الأسماء المتأثرة لم تكن عشوائية. تحدد سجلات Comodo وMicrosoft شهادات لوجهات اتصال وهوية رئيسية: Google، Yahoo، Skype، إضافات Mozilla، Microsoft Live، واسم "Global Trustee". هذه الأهداف ذات مغزى لأنها أماكن قد يقوم فيها المستخدم بالمصادقة، أو تحميل شيفرة موثوقة، أو تلقي اتصالات حساسة.

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

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

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

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

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

استجابة جيدة للحادثة ما زالت تترك أسئلة دون إجابة

تضمنت استجابة Comodo العامة حقائق مفيدة: التاريخ، واختراق حساب سلطة التسجيل، والتسع شهادات، وأسماء النطاقات والأرقام التسلسلية، والإبطال الفوري، ولغة مراقبة OCSP، ونفي اختراق البنية التحتية للـ CA و HSM، والمحاولة اللاحقة المحظورة. أضاف بائعو المتصفحات والمنصات استشاريات عامة. بالنسبة لعام 2011، هذا سجل أفضل من العديد من الحوادث.

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

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

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

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

ما غيرته الحادثة في محادثة الثقة

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

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

يعكس مشهد المعايير والسياسات اليوم هذا التحول. توفر المتطلبات الأساسية لمنتدى CA/Browser خط أساس عام أكثر رسمية للتحقق من النطاق والإبطال. تنشر Mozilla وChromium وApple وMicrosoft توقعات برامج الجذور. يوفر تسجيل شفافية الشهادات لمالكي النطاقات والمتصفحات مصدر بيانات عام للشهادات الصادرة. توفر CCADB تنسيق برامج الجذور ومعلومات سلطات الشهادات العامة. لا توجد أي من هذه الآليات مثالية، لكنها معًا تجعل من الصعب على سلطة الشهادات معاملة الحادثة كمشكلة خدمة عملاء خاصة فقط. (المتطلبات الأساسية لمنتدى CA/Browser،CCADB،سياسة شفافية الشهادات في Chrome)

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

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

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

اختبار مساءلة أفضل للإصدار المفوض

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

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

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

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

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

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

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