الخلاصة

  • يفرض RFC 9674 أن تشترك إشعارات RRDP ومراجع Snapshot وDelta وأهداف HTTP redirect في scheme وhost وport نفسها.
  • يثبت كشف cross-origin مخالفة حد الاسترجاع، لا نية عدائية؛ أما نجاح same-origin فلا يثبت سلامة كائن RPKI أو حداثته أو أثره في التوجيه.
  • تأتي بعد فحص الأصل أدلة أخرى: بنية RRDP والجلسة والرقم التسلسلي والـhash، ثم الشهادات وCRL والmanifest والكائنات الموقعة والcache المحقق وجلسة الموجّه والسياسة المحلية.

ظهر في سجل النظام تحذير cross-origin، فقفز التقرير مباشرة إلى عبارة «محاولة هجوم». لكن السجل لم يسمِّ مهاجماً ولم يثبت اختراقاً. لقد أثبت أمراً أضيق: بدأ الاسترجاع من الأصل الذي عيّنه ملف الإشعار، ثم طلب redirect الانتقال إلى أصل مختلف.

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

المخالفة ليست حكماً على النية

يعرّف RFC 6454 الأصل من scheme وhost وport. لا يكفي الاسم التجاري ولا ملكية النطاق الأعلى. ويختلف http عن https حتى مع المضيف نفسه، كما يختلف المنفذان والخادمان المختلفان.

في RFC 8182، يشير rpkiNotify في SIA لشهادة الموارد إلى Update Notification File. يسمي الملف session وserial وSnapshot وDeltas ويضع hashes للملفات المشار إليها. لم يمنع النص الأول صراحة المراجع العابرة للأصل ولم يحدد مصير redirect إلى أصل آخر.

يضيف RFC 9674 التزامين متقابلين. على Repository Server إبقاء المراجع وإعادة التوجيه داخل أصل الإشعار. وعلى Relying Party المقارنة والرفض والتسجيل. لا ينقل ذلك cookies أو JavaScript أو CORS إلى RRDP؛ بل يستعير فقط protection domain المبني على URI.

ومن هنا يجب ضبط اللغة. يسجل cross-origin حقيقة بروتوكولية، لكنه لا يحدد هل السبب خطأ إعداد، انتقال CDN، وثيقة قديمة أم فعل متعمد. لا يجوز أن تتحول آلية منع إلى آلية إسناد اتهام.

النجاح النهائي لا يمحو الطريق

يصف RFC 9110 redirect بأنه عمل إضافي عند URI أخرى. إذا احتفظ dashboard بالاستجابة النهائية 200 وحذف سلسلة Location، فقد حذف الدليل الذي يقرر قبول RRDP.

ينبغي حفظ URI في SIA، والأصل بعد التطبيع، وكل مرجع في notification، وكل استجابة وهدف redirect، وقرار المقارنة قبل المتابعة. كما لا يكفي hash صحيح. فهو يثبت أن الملف المسترجع يطابق الوعد، لكنه لا يجيز تحميله من principal آخر ولا يلغي حمل الموارد المفروض على الخادم الآخر والعملاء.

والعكس صحيح: same-origin لا يجعل المحتوى سليماً. قد يعيد الخادم XML غير صالح أو serial غير مناسب أو bytes لا تطابق hash. يحمي فحص الأصل السلطة؛ وتحمي فحوص أخرى البنية والحالة والمحتوى.

بعد الأصل تبدأ سلامة RRDP

يلزم RFC 8182 التحقق من شكل notification وschema، وربط session_id بموقع الملف، واستمرارية سلسلة Delta، وتطابق session وserial، ومطابقة hashes. وقد يؤدي رفض Delta إلى Snapshot؛ أما رفض Snapshot فيمنع استخدام RRDP.

يمكن تجربة access method بديل مذكور في SIA. لكنه مسار استرجاع جديد لا يغير حكم الجلسة المرفوضة.

ثم تأتي طبقة RPKI نفسها. يفصل RFC 6480 بين PKI للموارد والكائنات الموقعة والمستودع الموزع. يحدد RFC 6487 الشهادات وCRL والتحقق من المسار. ويحدد RFC 9286 رقم manifest وأوقاته وقائمة أسماء الملفات وhashes.

يمكن إذن أن يصل Snapshot من الأصل الصحيح ويطابق hash ثم تفشل شهادة أو CRL أو manifest أو ROA. إذن الاسترجاع ليس تحققاً، والتحقق ليس نتيجة توجيه.

من cache إلى الموجّه سلسلة أخرى

يسمي RFC 7115 المجموعة التي تحقق منها RP فعلاً validated cache. ويحدد RFC 8210 نقلاً آخر إلى الموجّه بإصدار وجلسة ورقم تسلسلي مستقل. أما RFC 6811 فيقدم حالة origin validation تدخل في سياسة محلية.

لذلك يجب فصل إيصال الأصل، وإيصال RRDP، ونتيجة التحقق، والـpayload المرسل، واستلام الموجّه، وقرار السياسة، والمسار المرصود. قد تنجح طبقة وتفشل التالية. ولا يشرح مؤشر «RPKI أخضر» واحد أين حدث الفرق.

القياس التاريخي لا يصف الحاضر كله

ذكر RFC 9674 أنه لم ير مراجع cross-origin في أرشيف الإشعارات الذي فحصه بين أكتوبر 2021 وأكتوبر 2024، وأن خادماً واحداً استخدم redirect من الأصل نفسه في نافذة أخرى من 2024. استُخدم ذلك لإثبات قابلية نشر القاعدة حينها.

ليس هذا مسحاً عالمياً في 2026. يجب الاحتفاظ بالفترة والعينة والسؤال، تماماً كما يجب الاحتفاظ بالأصل والجلسة عند تحليل حدث داخلي.

تدعم المواصفة الأولية الدنيا قاعدة مشتركة ضيقة لا تستولي على كل قرار محلي. وتفصل طبقات الواقع بين المؤسسة وURI والبايت والكائن المحقق والمسار. أما أولوية الكود الجاري فتمنع تحويل نص المعيار إلى دليل على تنفيذ RP أو الموجّه.

حد RFC 9674 واضح: لا توسع notification سلطة الاسترجاع بصمت. وضوح هذا الحد لا يسمح بتوسيعه إلى حكم على النية أو صحة الإنترنت.

المصادر