في NSD، لا ينبغي لشهادة ثانية سليمة أن تعطل الأولى

الخلاصة

• يتضمن NSD 4.15.2، الصادر في 2 سبتمبر، إصلاحًا يفحص اسم شهادة العميل مع شروط العنوان وTSIG الواردة في بند الوصول نفسه.
• كان البلاغ الأصلي عن رفض نقل مشروع عند وجود هوية شهادة ثانية، لا عن اختراق مثبت. وتختبر التعديلات هويتين صحيحتين، دون أن تغطي جميع تركيبات إعداد البلاغ.

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

وصف بلاغ منشور في 24 يوليو اختبارًا باستخدام NSD 4.14.0 من EPEL على RHEL 9.8 بصفته الخادم الأساسي، مع خادمين ثانويين يعملان ببرامج أخرى. لكل ثانوي عنوان واسم شهادة منفصلان، بينما تستخدم قاعدتا السماح مفتاح TSIG مشتركًا. أظهرت السجلات نجاح مصافحة TLS وقبول TSIG ومطابقة الاسم الأول، ثم عدم تطابق الاسم الآخر ورفض النقل. وعند إبقاء قاعدة واحدة فقط نجح الطلب.

في 28 أغسطس، قال أحد القائمين على الصيانة إنه أعاد إنتاج المشكلة وأصلحها. وأدرج إعلان الإصدار في 2 سبتمبر التصحيح صراحة. وكانت صفحة التنزيل الرسمية لا تزال تعرض 4.15.2 بوصفه الإصدار الحالي عند التحقق في 8 سبتمبر.

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

تجميع الشروط لا إلغاء أحدها

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

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

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

الاختبار يحدد نطاق الثقة

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

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

وهناك قاعدة أخرى تسمح، على نحو منفصل، بطلبات معتمدة على TSIG عبر TLS عادي أو TCP. هذا بديل مصرح به في الإعداد، لا تجاوز جديد للحماية. ويميز RFC 9103 بين التحقق من الهوية وسرية المحتوى: TSIG لا يشفر بيانات المنطقة بنفسه. أما حماية مجموعة النقل كلها فتتطلب سياسة تشمل كل علاقة نقل معنية، وليس نجاح قناة مشفرة واحدة.

ويجب فصل هذا الإصلاح عن CVE-2026-12490 الوارد في نشرات NLnet Labs الأمنية. تلك مشكلة مختلفة لتجاوز اشتراط الشهادة، أُعلنت في يونيو وأُصلحت في 4.14.3. لا يجوز إلحاق رقمها أو نطاق نسخها المتأثرة بحالة رفض الهويات المتعددة هنا. ولا تثبت المصادر استغلالًا جديدًا أو عددًا للعملاء المتضررين أو قائمة كاملة بالإصدارات المتأثرة.

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