[ أمن النقل ]

فشل التحقق من صحة DANE بعد الشهادة أو تغيير المفتاح

قم بتشخيص كسر DANE من خلال مقارنة الشهادة المقدمة وإجابة TLSA الآمنة والجدول الزمني للنشر قبل تغيير سياسة الثقة.

بواسطة فريق البحث EmailAuth · 3 دقائق قراءة

[النقاط الرئيسية]

  • افصل بين ثقة DNS ومصافحة TLS وفشل مطابقة الارتباط.
  • قارن بايتات DER المحددة من كل نقطة نهاية نشطة.
  • إصلاح المفتاح المغطى وحالات DNS دون إزالة الأمان بصمت.
في هذه الصفحة

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

الحفاظ على الملاحظة الفاشلة

مراجع: RFC 7672 §2, RFC 7672 §3.

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

التمييز بين فشل المصافحة وفشل المصادقة بعد المصافحة. لا تثبت مهلة الشبكة أن ملخص TLSA غير متطابق. وعلى العكس من ذلك، فإن الحصول على شهادة لا يثبت وجود سلسلة DNSSEC موثوقة ولا مصادقة DANE ناجحة. يحدد RFC 7672 خطوات الاكتشاف والتحقق بشكل منفصل. RFC 7672 الأقسام 2 و 3.

تحقق من الاستخدام والمحدد قبل مقارنة البايتات

مراجع: RFC 6698 §2.1.2, RFC 6698 §2.1.3, RFC 7672 §4.

بالنسبة لاقتران 3 1 1، قم باستخراج DER SPKI الخاص بالشهادة المقدمة وحساب SHA-256. يمكن أن يؤدي تجديد الشهادة الذي يعيد استخدام نفس المفتاح إلى ترك هذا الملخص دون تغيير. لا يمكن تدوير المفتاح. باستخدام محدد الشهادة الكاملة، تقوم الشهادة المجددة بتغيير الاقتران حتى إذا تم الاحتفاظ بالمفتاح. لا تستخدم بصمة شهادة المتصفح بالتبادل مع بصمة SPKI.

قامت أداة OpenSSL التي تم الاحتفاظ بها في 7 نوفمبر 2026، والتي تم فحصها ولكن لم يتم إعادة تشغيلها هنا، بإنشاء الشهادتين A وB بمفاتيح مختلفة وإعادة إصدار A2 بمفتاح A. تظهر حساباتها المسجلة أن A وA2 يتشاركان في ملخص SPKI المحدد بينما يختلف B. ثم يقوم بعد ذلك بمقارنة B مع ارتباط A وفشل السجلات بشكل متعمد. يستخدم الاختبار بايتات شهادة حقيقية تم إنشاؤها ولكنه دليل محلي وتركيبي وليس حادث إنتاج تم التقاطه.

إعادة بناء DNS وتوقيت نقطة النهاية

مراجع: RFC 7671 §8.1, RFC 7672 §2.1.

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

تحقق من جميع الواجهات الخلفية وعائلات العناوين. قد يحتفظ الخادم الذي فشل في إعادة التحميل بـ A بينما تستخدم الخوادم الأخرى B. ستفشل مجموعة TLSA الجديدة فقط في جزء فقط من حركة المرور. تحتوي حالات فشل DNSSEC على جدول زمني آخر: يجب فحص التوقيعات والتفويض والتحقق من صحة المحلل دون التعامل بشكل عرضي مع البيانات الزائفة على أنها غير موقعة. RFC 7672 الأقسام 2.1 و4.

استعادة الاتساق بدلا من تعطيل الشيكات

مراجع: RFC 7672 §3.1.1, RFC 7672 §4.

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

بالنسبة إلى DANE-EE، لا تستورد كل قاعدة PKIX للمتصفح في التشخيص: استخدام الشهادة الخاص به له دلالات مصادقة محددة، بما في ذلك عدم وجود متطلبات مطابقة اسم الشهادة وتجاهل انتهاء صلاحية الشهادة لاستخدام DANE-EE 3 بموجب RFC 7672 §3.1.1. لا تقم بتوسيع هذه القاعدة المحددة لتشمل كل استخدام لـ TLSA. وهذا لا يعفي الشهادات التشغيلية منتهية الصلاحية حيث يستخدم المرسلون الآخرون PKIX أو MTA-STS. بشكل منفصل، تحتوي أدلة المراجعة التي تم الاحتفاظ بها في 7 نوفمبر 2026 على استرجاع ذو طابع زمني STARTTLS جلسات. تم فحص الجلسات ولكن لم يتم إعادة تشغيلها لهذه المراجعة. يلاحظ العميل الخاضع للرقابة الشهادة B عند منفذ 127.0.0.1 المسجل، ويستخرج SPKI النظير ويرفض اقتران A فقط. يقبل عنصر التحكم A-plus-B المتداخل الذي تم تصحيحه المسار. بشكل منفصل، يرفض التحقق من شهادة Python/OpenSSL B مقابل مادة الثقة A، بينما ينجح A. تحتفظ حزمة المراجعة الخاصة بسبعة نصوص وبايت شهادة نظير للحالات الأربع التي تصل إلى الحصول على الشهادة. لا تحتوي حالات المصافحة الفاشلة وحالات عدم STARTTLS على وحدات بايت لشهادة النظير التي تم التقاطها. هذا عميل مختبر صغير بمدخلات TLSA مهيأة، وليس نتيجة أو إنتاج DNSSEC للإنترنت MTA حادثة. لم يتم إرسال أي رسالة. لا يزال قبول الإنتاج يحتاج إلى نقطة النهاية المقصودة وتتبع المرسل.

[ الوجبات الجاهزة ]

إصلاح المفتاح المغطى وحالات DNS دون إزالة الأمان بصمت.

[ حسب الدور ]

ماذا يعني هذا بالنسبة لك

اختر دورك للخطوات العملية التالية.

تكنولوجيا المعلومات / مدير البريد

قارن المواد المقدمة

قد تختلف الملفات الموجودة على القرص عن الشهادات الموجودة على السلك.

الخطوات التالية

  1. التقاط عناوين IP لنقطة النهاية.
  2. استخراج المحدد الصحيح.
  3. قارن مجموعات RRsets المخزنة مؤقتًا والحالية.

كبير مسؤولي أمن المعلومات / SecOps

تجنب الإصلاحات الرجوع إلى إصدار أقدم

لا يتم استعادة ضمان مرور اتصال أضعف DANE .

الخطوات التالية

  1. حافظ على تمكين التحقق من الصحة.
  2. قم بمراجعة التسوية الرئيسية بشكل منفصل.
  3. الاحتفاظ بالتحقق من جانب المرسل.

المؤسس / غير التقنية

الحفاظ على الجدول الزمني للحادث

قد يؤدي الطرح الجزئي إلى تأثير متقطع على الأعمال.

الخطوات التالية

  1. سجل الفترات المتضررة.
  2. تحديد أصحاب الإصدار.
  3. طلب الأدلة قبل الإغلاق.

[ الأسئلة الشائعة ]

الأسئلة المتداولة

هل كل تجديد يغير ملخص TLSA؟

لا. يعتمد الأمر على المحدد وما إذا كان المفتاح العام يتغير أم لا.

RFC 6698 §2.1.2 RFC 7672 §4

هل بصمة المتصفح هي المقارنة الصحيحة؟

ليس تلقائيا. يقوم اقتران 3 1 1 بتجزئة DER SPKI بدلاً من الشهادة بأكملها.

RFC 6698 §2.1.2

هل تثبت المهلة عدم تطابق DANE ؟

لا، قد يحدث ذلك قبل مقارنة الشهادات.

RFC 7672 §3

لماذا يمكن أن تفشل حركة مرور IPv6 فقط؟

قد تخدم نقطة نهاية IPv6 مواد شهادة مختلفة أو قد يكون بها فشل مختلف في الشبكة.

هل يدحض DNS الجديد مشكلة ذاكرة التخزين المؤقت السابقة؟

لا، من الممكن أن تحتوي ذاكرات التخزين المؤقت للمرسل السابقة على مجموعة اقترانات مختلفة.

RFC 7671 §8.1

هل يجب أن أحذف TLSA على الفور؟

التحقيق واستعادة الاتساق. لا يؤدي الحذف إلى مسح السياسة المخزنة مؤقتًا على الفور.

RFC 7672 §4

هل يستخدم DANE-EE والتحقق من صحة المتصفح قواعد متطابقة؟

لا، قم بتطبيق قواعد استخدام الشهادة في RFC 7672 بدلاً من افتراض دلالات PKIX.

RFC 7672 §3.1.1

ما هي أدلة الاتصال التي تم تلخيصها؟

تم الاحتفاظ به في 7 نوفمبر 2026، وتم فحص سجلات STARTTLS للاسترجاع، وليس إعادة تشغيلها. تغطي سبعة نصوص وأربعة لقطات لشهادات النظير التركيبة المحدودة؛ تظل أدلة DNSSEC للإنترنت وأدلة MTA الخاصة بالإنتاج معلقة.

[ مصادر ]

مصادر

  1. RFC 6698

    الأقسام §2.1.2 · §2.1.3

  2. RFC 7671

    الأقسام §8.1

  3. RFC 7672

    الأقسام §2 · §2.1 · §3 · §3.1.1 · §4

[ مسرد ]

مسرد

دان-EE
استخدام TLSA 3، مصادقة شهادة الكيان النهائي أو المفتاح من خلال DANE .
الطرح الجزئي
عملية نشر تخدم فيها نقاط النهاية النشطة المختلفة إصدارات مختلفة.
محدد
حقل TLSA يحدد بيانات الشهادة المستخدمة للمطابقة.

مصدر المؤسسة

لماذا كبار المؤسسات المالية والحكومات تقاعدوا من لوحات معلومات أمان البريد الإلكتروني الخاصة بهم.

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

EmailAuth هي منصة مصدر البريد الإلكتروني الوكيل. وكلاؤنا ينفذون p=reject، حافظ على محاذاة المرسلين الخارجيين وانقل نطاقاتك إلى كاملها RFC 9989 الامتثال، وهو معيار DMARC الجديد، مع إمكانية التدقيق البشري في الحلقة.

الحكومات المؤسسات الكبيرة المؤسسات المالية من المستوى الأول

SaaS · إيجار مخصص · Air-gapped محليًا · تشفير BYOK

قاعدة المعرفة