الخلاصة

  • لا تصبح مجموعة TLSA دليلاً لـ DANE إلا بنتيجة DNSSEC؛ فالبيانات غير الآمنة أو غير المحددة غير قابلة للاستخدام، وبيانات bogus تفرض الفشل.
  • يحدد استخدام الشهادة والمحدد ونوع المطابقة ما تتم مقارنته وقواعد التحقق المطبقة.
  • قد يظل الارتباط المنشور بصورة آمنة غير قابل للاستخدام أو لا يطابق الشهادة أو المفتاح الذي يقدمه الخادم فعلاً.
  • يجب فصل حالات منشور وآمن وقابل للاستخدام ومطابق ومقبول.

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

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

النشر هو الحالة الأولى فقط

تعرّف RFC 6698 ‏TLSA من خلال استخدام الشهادة والمحدد ونوع المطابقة وبيانات الارتباط. تحدد المعلمات الثلاث ما إذا كان الارتباط يقيد مسار هيئة شهادات عامة أو يقدم مرساة ثقة أو يحدد شهادة نهائية صادرة عن النطاق؛ وهل تُقارن الشهادة كاملة أم SubjectPublicKeyInfo؛ وهل تستخدم البيانات الأصلية أم SHA-256 أو SHA-512.

ويشتق اسم الاستعلام من منفذ الخدمة وبروتوكول النقل والنطاق الأساسي لـ TLSA. قد يؤدي استعلام اسم آخر أو التوقف عند اسم مستعار غير آمن إلى استخدام بيانات DNS صحيحة في قرار خاطئ. كما تدخل توسعة CNAME المتحقق منها بأمان في اختيار النطاق الأساسي وفق RFC 7671. حفظ RDATA وحده يفقد هوية الخدمة المقصودة.

DNSSEC يقرر قابلية استخدام الارتباط

تجعل RFC 6698 حالة DNSSEC حاسمة. يجب استخدام مجموعة TLSA الآمنة ما لم تمنع السياسة المحلية ارتباطاً بعينه. تستلزم استجابة bogus منع TLS أو قطعه. ولا يمكن استخدام مجموعة غير آمنة أو غير محددة لمصادقة TLSA.

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

إذا لم يبق أي ارتباط قابل للاستخدام، تعالج التطبيقات TLS بالطريقة المعتادة من دون مدخل TLSA. وإذا بقي واحد أو أكثر، تنفذ المقارنات المطلوبة ويجب أن تعثر على تطابق. لذلك قد يتعامل عميلان بقدرات أو سياسات مختلفة مع المجموعة نفسها بطرق مختلفة.

على الشهادة المقدمة أن تحقق السجل

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

تضيف RFC 7671 متطلبات تشغيلية. يحتاج DANE-TA إلى مادة سلسلة كافية، وفي حالات محددة إلى شهادة مرساة الثقة من الخادم. يمكن لـ DANE-EE مع محدد SPKI البقاء عبر التجديد إذا لم يتغير المفتاح، لكنه يفشل إذا قدم الخادم مفتاحاً آخر. ولا تطبق مرونة خوارزمية الملخص إلا بعد استبعاد الارتباطات المشوهة أو غير المدعومة.

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

الزمن يفصل النشر عن القبول أيضاً

تقيد TTL لسجل TLSA وصلاحية RRSIG وعمر ذاكرة المحلل وترتيب النشر الاستنتاج. تحذر RFC 7671 من فشل العملاء الذين يحتفظون بارتباط TLSA قديم بعد تغيير غير مخطط للشهادة أو السلسلة. وتمدد مدة توقيع طويلة زمن إمكان إعادة تشغيل بيانات DNS قديمة موقعة.

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