اقرأ تقرير TLS كملاحظة محدودة
A TLS-RPT يصف التقرير ما لاحظه أحد أنظمة الإبلاغ أثناء محاولة إجراء اتصالات النقل بموجب سياسات معينة. ويمكنه توجيه التحقيق في مفاوضات TLS أو الشهادات أو استرجاع السياسة. إنه ليس دفتر أستاذ للتسليم على مستوى الرسالة، أ DMARC حكم أو دليل على أن كل مرسل يرى نفس التكوين. ابدأ بالمراسل والنافذة الزمنية والسياسة المطبقة قبل تفسير أعدادها.
لا يوجد تقرير أصلي أو دليل اتصال العميل مصاحب لهذه المقالة. الأرقام المذكورة أدناه خيالية، والطريقة عبارة عن عملية مراجعة مقترحة. يحتاج حادث الإنتاج إلى التقرير غير المتغير وسياق الاستلام الخاص به والاتصال المؤيد أو ملاحظات الاستضافة. لا تقم بإعادة تسمية تقرير توضيحي باعتباره انقطاعًا ملحوظًا.
التحقق من سياق الإبلاغ
يطلب المجال الإبلاغ من خلال أ سجل TXT في _smtp._tls.<domain>، باستخدام TLSRPTv1 ووجهة rua واحدة أو أكثر. ولا يفرض هذا الطلب في حد ذاته سياسة خاصة بأمن النقل. التقارير يمكن أن تقلق MTA-STS, DANE أو غياب السياسة احتفظ بطلب الإبلاغ والمنظمة المتلقية المقصودة عند جمع الأدلة لاحقًا، خاصة عندما تقوم الخدمة بمعالجة التقارير لعدة مجالات. RFC 8460 الأقسام 2-3
يتطلب التقرير الذي يتم تسليمه عبر SMTP مجالًا صالحًا لإعداد التقارير توقيع DKIM الذي لا يستخدم l= علامة طول الجسم. عام DKIM المرور بتغطية جزئية للجسم لا يفي بمتطلبات الإبلاغ هذه. يوجه RFC 8460 المستلمين إلى تجاهل التقارير بدون التوقيع المطلوب ويحظر تحديد طول النص بحيث لا يمكن إلحاق المحتوى المضلل خارج التغطية الموقعة. قم بتصديق الرسالة الأصلية والاحتفاظ بها قبل الوثوق بمرفق JSON المستخرج. الأسماء وحقول الاتصال داخل JSON هي مطالبات، وليست مصادقة مستقلة للمرسل. تعامل مع المرفقات على أنها مدخلات غير موثوقة وقم بمعالجتها باستخدام حدود حجم الملف والمحلل المناسب. RFC 8460 الأقسام 3 و 7
إنشاء النافذة والسياسة المطبقة
اقرأ اسم المنظمة ومعرف التقرير والنطاق الزمني معًا. توصي المواصفات بيوم UTC كامل وتأخير التسليم لتقليل طفرات المعالجة. ولذلك لا يلزم أن يتطابق وقت الاستلام مع وقت الحدث. احتفظ بسجل إلغاء البيانات المكررة مرتبطًا بالمبلغ المعتمد وهوية التقرير، مع تجزئة الملف الأصلي، قبل تجميع عمليات التسليم المتكررة. إن التصميم الدقيق لإلغاء البيانات المكررة هو توصية تشغيلية، وليس حقل مخطط إلزامي. RFC 8460 الأقسام 4.1 و4.4
حقل السياسات عبارة عن مصفوفة، حتى بالنسبة لسياسة مطبقة واحدة. بالنسبة لكل إدخال، افحص نوع السياسة ومجال السياسة وسلسلة السياسة ومعلومات MX المعمول بها. يجب تفسير التقرير حول sts مقابل سياسة MTA-STS المبلغ عنها، والتي قد تختلف عن الهيئة المستضافة حاليًا. يمكن أن يفسر تاريخ السياسة المخبأ هذا الاختلاف دون الإشارة إلى أن التقرير ملفق. RFC 8460 القسمان 4 و4.4 RFC 8461 القسم 3.3
اعمل من خلال التهم الخيالية بعناية
تخيل تقريرًا موثقًا من Sender Delta الخيالي يغطي يومًا واحدًا بالتوقيت العالمي المنسق (UTC) لموقع example.com . يصف إدخال sts الفردي سياسة التنفيذ. يحتوي الملخص على 480 جلسة ناجحة و20 جلسة فاشلة. تسرد تفاصيل الفشل 12 جلسة منتهية الصلاحية للشهادة لـ mx1.example.com و8 جلسات غير مدعومة لـ starttls لـ mx2.example.com . في هذه الحالة المخترعة، يُشترط أن تكون المجموعتان التفصيليتان منفصلتين.
يدعم الملخص مشاركة الفشل 20 مقسومة على 500، أو 4 بالمائة، بين الجلسات التي تم حسابها لهذا المراسل لهذا الإدخال والفاصل الزمني. ولا يثبت أن 4 بالمائة من الرسائل قد فقدت، لأن الجلسات ليست رسائل والمحاولات اللاحقة قد يكون لها نتائج مختلفة. كما أنها لا تقدر معدل الفشل العالمي لنطاق الاستقبال دون معلومات حول المرسلين الآخرين وتغطية التقارير. RFC 8460 القسم 4.2
تتطلب أعداد التفاصيل الحقيقية عناية أكبر من هذا المثال البسيط. أنواع الفشل غير حصرية، وقد تواجه محاولة واحدة أخطاء متعددة. قد تصف العديد من إدخالات السياسة نفس المجال و MX . يمكن أن يؤدي جمع كل صف من التفاصيل، أو أعداد كل سياسة، إلى مضاعفة حساب المحاولات الأساسية. احتفظ بكل مدخل سياسة وملخصه بدلاً من فرض كل تقرير في إجمالي واحد غير مؤهل. RFC 8460 القسم 4
تحويل أنواع النتائج إلى أسئلة التحقيق
بالنسبة لمجموعة انتهاء الصلاحية الخيالية، اطلب اسم المضيف المتلقي وعنوان الاستلام ونافذة الحدث وتفاصيل الشهادة المتاحة. والسؤال التالي هو ما إذا كان الخادم قد قدم شهادة منتهية الصلاحية في ذلك الوقت، وليس ما إذا كان لدى المشغل الآن ملف غير منتهي الصلاحية على القرص. ل STARTTLS المجموعة، قم بفحص نقطة نهاية SMTP ذات الصلة وإعلانها أو استجابتها. لم تنشئ أي من الملاحظتين مشكلة HTTPS لمضيف السياسة. RFC 8460 القسم 4.3.1
فشل السياسة لها تسميات منفصلة. يشير خطأ sts-policy-fetch-error إلى فشل الاسترجاع؛ sts-policy-invalid يتعلق بالسياسة العامة؛ يعني sts-webpki-invalid أنه لا يمكن مصادقة السياسة من خلال التحقق من صحة PKIX. استخدم رمز سبب الفشل وسياق نقطة النهاية للمبلغ حيثما كان ذلك متاحًا. تعمل التسمية العريضة على تضييق نطاق التحقيق ولكنها لا تثبت ما إذا كان جدار الحماية أو تغيير التوجيه أو سلسلة الشهادات أو استجابة التطبيق قد تسبب في ذلك. RFC 8460 القسم 4.3.2.2
الحفاظ على المخطط وتحذيرات المصدر
لا تقم بنسخ مثال JSON الخاص بـ RFC بشكل أعمى إلى أداة التحقق الصارمة. يتضمن سجل الأخطاء الحالي الخاص به إدخال "محتجز لتحديث المستند" رقم 6241 فيما يتعلق بمضيف mx العددي للمثال مقابل تعريف الصفيف. الحفاظ على التقرير الأصلي، وتسجيل التمثيل الفعلي وتوثيق أي معالجة لتوافق المحلل اللغوي. التصحيح المعلق ليس هو نفس حالة التصحيح الذي تم التحقق منه. RFC 8460 القسم 4.4 RFC 8460 خطأ
يوضح الخطأ 8070 الذي تم التحقق منه أن المُبلغ قد يختار محاولة التسليم إلى نقطة واحدة فقط من نقاط نهاية التقارير المتعددة. لذلك، لا يثبت صندوق البريد الفارغ للوجهة الثانية أنه لم يتم إنتاج أي تقرير. يحتوي السجل أيضًا على الإدخالات المبلغ عنها والموقوفة والمرفوضة؛ الاحتفاظ بحالاتهم بدلاً من التعامل مع كل تغيير مقترح كنص بروتوكول حالي. RFC 8460 خطأ
أغلق الحلقة دون المطالبة بالصحة العامة
قم بتعيين نقطة النهاية المشتبه بها لمالكها، واحتفظ بالتقرير الأصلي وقارن أي إصلاح معتمد مع النوافذ اللاحقة من نفس المُبلغين. لا يلزم الإبلاغ عن بعض حالات فشل الشبكة العابرة، وتختلف مشاركة المرسل. ويعتبر الاتجاه التحسن دليلاً ضمن تلك التغطية، وليس دليلاً على أن جميع مسارات النقل سليمة. تظل التقارير الأصلية الموثقة وتتبعات نقطة النهاية وسجل الاستضافة والمراجعة المستقلة متطلبات مفتوحة لهذه المسودة. RFC 8460 الأقسام 4.3.4 و7