الخلاصة
- أعلنت Let's Encrypt في 29 فبراير 2020 أن برنامج سلطة الشهادات Boulder كان يتضمن خطأ في إعادة فحص سجلات DNS CAA عند طلبات الشهادات التي تحتوي أسماء متعددة [1].
- يعرف RFC 8659 سجل CAA بأنه سجل DNS يسمح لصاحب اسم النطاق بتحديد سلطات الشهادات المسموح لها بإصدار شهادات لذلك النطاق [2].
- لم تكن مسألة المساءلة هي دعم Let's Encrypt العام لـ CAA، بل ما إذا كان كل اسم ضمن تحقق معاد استخدامه قد خضع لفحص حديث قبل الإصدار [1].
- تصف صفحة Let's Encrypt الرسمية الخدمة بأنها سلطة شهادات يوفرها Internet Security Research Group. يستخدم ربط دليل BTW هنا الكيان المنشور
internet-societyدون تغيير الموضوع الواقعي للحادث [3].
ما الذي حدث
يصف إشعار Let's Encrypt عيبا اكتشف في 29 فبراير 2020 في Boulder. يفحص Boulder عادة سجلات CAA عندما يتحقق من سيطرة المشترك على اسم نطاق. وبما أن بعض عمليات التحقق تبقى قابلة للاستخدام لفترة بعد الفحص الأول، فقد تحتاج سلطة الشهادات إلى فحص CAA مرة أخرى قبل الإصدار مباشرة. قالت Let's Encrypt إن القاعدة المطبقة تتطلب فحص CAA خلال ثماني ساعات قبل الإصدار عندما يكون التحقق أقدم من ذلك [1].
كان نمط الفشل محددا. عندما يحتوي طلب شهادة على أسماء نطاقات متعددة تحتاج إلى إعادة فحص CAA، كان Boulder يختار اسما واحدا ويفحصه عدة مرات بدلا من فحص كل اسم ذي صلة. لذلك كان يمكن أن يمر طلب ما رغم أن اسما أو أكثر لم يحصل على فحص تفويض DNS الحديث المتوقع. قالت Let's Encrypt إنها أكدت الخطأ في 03:08 UTC، وأوقفت الإصدار في 03:10 UTC، ونشرت إصلاحا في 05:22 UTC ثم أعادت تفعيل الإصدار [1].
هذا الجدول الزمني مهم لأن مساءلة سلطة الشهادات لا تثبت بعبارة أن الكود أصلح. كان على النظام أيضا تحديد الشهادات التي قد تكون تأثرت، وإخطار المشتركين، وتمكين الاستبدال، وتنفيذ الإبطال. لذلك شمل السجل العام تحديد العيب وإصلاح مسار الإصدار وتنظيف دورة حياة الشهادات [1].
لماذا CAA تحكم في DNS
يقدم RFC 8659 سجل CAA كآلية DNS تسمح لصاحب النطاق بتحديد سلطات الشهادات المخولة. ويصفه أيضا كتحكم إضافي لتقليل خطر الإصدار غير المقصود [2]. لذلك يمثل CAA حدا بين حالة DNS المنشورة وقرار سلطة الشهادات.
في سياق المخاطر والمساءلة، المهم ليس اسم العلامة على الشهادة. المهم هو سلسلة السلطة التشغيلية: ينشر مالك النطاق CAA، وتعيد بنية DNS الحالة التي تراها سلطة الشهادات، ويفسر البرنامج تلك الحالة، ويتوقع نظام المشترك الآلي تجديدا واسعا. إذا اختزلت هذه الخطوات في عبارة عامة مثل "نجح التحقق"، تصبح حدود الأدلة ضعيفة.
حد الدليل
الموضوع المباشر هو Let's Encrypt وخدمة ISRG كما تصفها المصادر الرسمية. يستخدم الربط entity:internet-society لأنه كيان منشور موجود في الإنتاج واستعمل سابقا في تغطية مرتبطة بثقة شهادات Let's Encrypt. هذا لا يعني أن Internet Society اتخذت قرار Boulder الهندسي. إذا تطلبت بوابة المالك كيانا مباشرا لـ ISRG، فيجب إيقاف المرشح بدقة قبل النشر.
ما الأدلة المطلوبة
يجب أن يوضح الإغلاق القابل للدفاع أي أسماء احتاجت إلى فحص CAA جديد، وما إجابات DNS التي اعتمدت عليها السلطة، وأي مسار برمجي اتخذ القرار، وأي شهادات دخلت النطاق، وكيف أبلغ المشتركون، وكيف اختبر منع التكرار. من دون ذلك، يبقى الإصلاح ادعاء خاصا داخل سلسلة ثقة عامة.
المصادر
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات