المجال الرئيسي
الأمن
ضمن فئة المجال الرئيسي، تجمع تحليلات الأمن التقارير حسب المجال الأساسي ليتمكن القراء من متابعة مجال مركّز من مجالات البنية التحتية للإنترنت أو الحوكمة أو أسواق الاتصالات أو رأس المال الرقمي. وتضم الصفحة المقالات ذات الصلة والأدلة العامة والمؤسسات والشركات والأشخاص والانتشار الإقليمي والتبعيات التشغيلية وسياق السوق التي قد تكون موزعة عبر صفحات فئات منفصلة. وتشرح الصفحة المجال ونوع الجهات الفاعلة المحتملة وسياق السوق أو الحوكمة والمادة المصدرية التي ينبغي للقراء استخدامها عند مقارنة المؤشرات. ويمكن للمشغلين والمحللين والمهتمين بالحوكمة أن يروا كيف يظهر المجال نفسه عبر الأحداث والملفات الشخصية وتحولات السوق والأدلة المستقاة من المصادر العامة والتبعيات الإقليمية وقرارات البنية التحتية طويلة الأجل بمرور الوقت.
ملف القضية
وُقّع الطلب، لكن حيازة المفتاح الخاص الآخر بقيت مجرد إقرار: RFC 9883
قد يثبت التوقيع الصحيح هوية صاحب الإقرار من دون أن يثبت تقنياً حقيقة ما أقر به. في RFC 9883 يوقّع مفتاح خاص سبق اعتماده طلباً جديداً، بينما تبقى حيازة مفتاح خاص مختلف لإنشاء المفاتيح ادعاءً تقبله سياسة جهة التصديق.
ملف القضية
ألزم RFC 9882 بكتابة SHA-512، لكنه لم يجعله جزءاً من كل توقيع
قد يكون الحقل في رسالة CMS صحيحاً وإلزامياً، ومع ذلك لا يصف العملية التشفيرية التي نُفذت فعلاً. يحوّل RFC 9882 هذه المفارقة إلى قاعدة تشغيلية واضحة: في أحد مساري ML-DSA يجب على الموقّع ذكر SHA-512 للتوافق، ويجب على المدقق تجاهل قيمة الحقل.
ملف القضية
حدّث RFC 9879 آلية MAC، لكنه لم يُحِل القارئ القديم إلى التقاعد
قد تعلن شاشتان نجاح استيراد ملف PKCS #12 نفسه، بينما تعني كل شاشة شيئاً مختلفاً. الأولى تحققت من PBMAC1 الجديد؛ والثانية لم تفهمه، فتجاوزت فشل التحقق ووصلت إلى مادة المفتاح المشفرة. وحّد RFC 9879 المسار الأول، لكنه لم يُلغِ إمكان المسار الثاني.
ملف القضية
حملت الحزمة شكلين، لكنهما لم يصبحا مفتاحاً واحداً بعد: RFC 9935
يمكن لحزمة مفتاح ML-KEM الخاص أن تضم البذرة المدمجة ومفتاح فك التغليف الموسّع معاً. يفيد ذلك التوافق، لكنه يخلق واجب إثبات: قبل إعادة الاشتقاق والمقارنة، لا يملك المستورد إلا قيمتين قابلتين للقراءة.
ملف القضية
سمّى OID حزمة المفتاح، لكنه لم يأذن باستخدامها: RFC 9939
ظهر في السجل نوع محتوى CMS معروف، واستطاع المحلل قراءة بنية PKCS #8. هذه حقيقة عن صيغة كائن وصل إلى النظام. ليست دليلاً على من يملك المفتاح الخاص أو من يحق له فكّه أو استعماله.
ملف القضية
سمّى المورد خادم التفويض، لكنه لم يمنح حقاً: حدّ الاكتشاف في RFC 9728
يمكن للمورد المحمي أن يدلّ العميل بدقة إلى موضع الخطوة التالية، من دون أن يسمح له بأي استدعاء لواجهة API. ميتاداتا RFC 9728 أداة لاكتشاف المسار وتنسيقه؛ ليست رمز وصول، ولا قرار قبول من خادم المورد، ولا دليلاً على أن عملية ما أنتجت أثراً.
ملف القضية
كانت محادثة التفويض ما تزال معلّقة، ولم تكن حقاً في واجهة API: حدّ الاستمرار في GNAP
قد يُسمح للعميل بمتابعة محادثة تفويض من دون أن يُسمح له باستدعاء واجهة API التي طلبها. تفصل RFC 9635 بين الأمرين: فاعتماد الاستمرار يدفع طلباً واحداً إلى الأمام لدى خادم التفويض؛ أما حق المورد، إن نشأ، فلا يظهر إلا لاحقاً وبفحص مختلف.
IETF
Sean Turner وإثبات المفتاح الخاص الذي لم يمنح إذن إصدار الشهادة
يمكن لطلب شهادة أن يحمل توقيعاً صحيحاً من دون أن يملك صاحبه حق الحصول على الشهادة المطلوبة. فالتوقيع يثبت أمراً محدوداً عن المفتاح؛ أما الهوية والاسم والتعديل الوسيط وقرار الإصدار فلها أدلتها وسلطاتها المستقلة.
IETF
Panos Kampanakis وجلسة SSH ذات الإيصالات الأمنية الثلاثة
يمكن لاتصال SSH واحد أن يستخدم تبادل مفاتيح هجيناً مع ML-KEM، وأن يثبت الخادم هويته بمفتاح مضيف مستقل، ثم يسمح لمستخدم بالدخول اعتماداً على بيانات اعتماد أخرى. تجتمع القرارات في قناة واحدة، لكنها لا تتحول إلى ضمان واحد.
IETF
Bas Westerbaan: مصافحة TLS الهجينة لم تجعل الشهادة مقاومة للكمّ
في انتقال TLS إلى ما بعد الحوسبة الكمّية تعمل ساعتان مختلفتان. الأولى تخص خصماً سلبياً يخزن الحركة اليوم كي يفكها غداً، والثانية تخص خصماً نشطاً قد يزوّر هوية الخادم مستقبلاً. تعالج RFC 10024 جزءاً مهماً من الساعة الأولى، لكنها لا توقف الثانية تلقائياً.
IETF
Daniel Fett: صادقت MFA على المستخدم، لا على سياق رمز QR
لم يُدخل المستخدم كلمة المرور في موقع مزيف، ولم يتجاوز المهاجم العامل الثاني. وصل المستخدم إلى الخدمة الحقيقية وأكمل المصادقة الصحيحة ثم منح الإذن بنفسه. ومع ذلك ذهبت الصلاحية إلى جهاز المهاجم، لأن النظام أثبت هوية صاحب القرار ولم يثبت مصدر الطلب الذي وافق عليه.
ملف القضية
تحققت الشهادة من الطرف، وبقيت PSK الخارجية بحاجة إلى أمين: RFC 9973 وحدود السلطة في TLS
قد يقال بعد فحص اتصال ما إن الشهادة صحيحة وإن الـ binder سليم وإن TLS أنهى المصافحة. هذه حقائق نافعة، لكنها لا تجيب عن السؤال الذي يهم مالك المخاطر: من أنشأ السر الخارجي، ومن يستطيع نسخه أو استعادته أو عرضه، ومن قرر أن الطرف الموثق يجوز له تنفيذ الفعل اللاحق؟ لا ينبغي لنجاح…
ملف القضية
وصل الـCookie مع الطلب، لكنه لم يثبت قراراً: RFC 10025 والسلطة المحيطة
قد يمر طلب تغيير حساس عبر اتصال آمن، ويحمل Cookie لجلسة معروفة، ويستقبل استجابة ناجحة. تلك وقائع مهمة، لكنها ليست جواباً عن صاحب الإرادة، ولا عن بقاء الجلسة مقبولة، ولا عن صلاحية الفعل، ولا عن تحقق أثره. يوضح RFC 10025 كيفية احتفاظ المتصفح بحالة وإعادتها؛ ولا يحوّل تلك الحالة إلى…
ملف القضية
وصل النص المشفر إلى المفتاح، لكنه لم يسمِّ مرسله: RFC 9180 والسلطة الغائبة في نمط HPKE Base
قد يفتح حامل المفتاح الخاص رسالة HPKE بنجاح، من غير أن يعرف ذلك النجاح من أرسلها أو ما إذا كان مخولاً أو أن محتواها ما زال صالحاً للتنفيذ. يضبط RFC 9180 عملية تشفير محددة؛ أما الاسم والسياق والزمن والسياسة والأثر فتبقى مسؤولية التطبيق الذي يستخدمها.
ملف القضية
تلقي أثرٍ لمسي لا يجيز كشف بيانات البيئة: RFC 9993 وحدود الحساسات والمُشغِّلات
يمكن لتدفق haptics أن يصل إلى جهاز يملك حساسات ومُشغِّلات. أحدهما يقرأ جانباً من العالم المادي، والآخر يؤثر فيه. لا يربط RFC 9993 بين الأمرين بترخيص واحد: قبول بيانات أثر لمسي لا يمنح جهة الإرسال حق الحصول على قياس الحساس أو فرض خرج مادي بلا سياسة محلية.
ملف القضية
وافق العنوان الخارجي على استقبال التقرير، لا على رؤية كل الرسالة: RFC 9991 وحدود إفصاح DMARC
قد يتحقق خادم البريد من أن مزوداً خارجياً وافق عبر DNS على استقبال تقارير الفشل الخاصة بنطاق معين. هذه خطوة ضرورية، لكنها تجيب عن سؤال واحد فقط: هل يقبل المزود علاقة التلقي؟ لا تجيب عن الحقول التي يحتاجها، ولا عمّن يستطيع قراءة متن الرسالة، ولا عن مدة الاحتفاظ أو القرار الذي قد…
IETF
Russ Housley وعنوان MAC الذي استطاعت الشهادة تسميته ولم تستطع جعله فريداً
تستطيع الشهادة تثبيت ستة أو ثمانية ثمانيات بدقة. لكنها لا ترى المنفذ الذي يستخدمها الآن، ولا الإطار الذي حملها، ولا الجهة المحلية التي سمحت بما حدث بعد التحقق.
IETF
Aaron Parecki وBFF الذي يمنع سرقة الرموز ولا يمنع اختطاف العميل
إبقاء رموز OAuth خارج JavaScript يزيل سلاحاً قوياً من يد المهاجم: لا توجد صلاحية محمولة يمكن نسخها واستعمالها من جهاز آخر. لكن RFC 10017 تضع حداً دقيقاً لهذا المكسب؛ فالشفرة الخبيثة داخل المصدر الصحيح تستطيع أن تطلب من BFF استعمال جلسة المستخدم ما دامت حية.
IETF
Hannes Tschofenig ومعرّف السلطة الذي لم يوقّع الرمز
يمكن لمفتاح أن يوقّع المكوّن المثبّت، ولمفتاح آخر أن يوقّع دليل EAT الذي يصف حالته. تفصل RFC 10013 بين الفعلين، وتمنع النظام من تحويل كلمة authority إلى تفويض عام يشمل المكوّن والرمز وقرار الوصول معاً.
ملف القضية
الغلاف يسمّي الدليل لكنه لا يربط الجهاز: RFC 9999 وحدود السلطة داخل مجموعة التصديق
قد يقدّم المعالج وSmartNIC ووحدة GPU ثلاثة تقارير موقعة وصحيحة، لكن جمعها في حاوية واحدة لا يثبت أنها تخص الخادم نفسه أو جلسة التقييم نفسها. يمنح RFC 9999 رسائل RATS شكلاً قابلاً للنقل، بينما يظل ربط مكونات الجهاز وتقييم الأدلة واتخاذ قرار الوصول مسؤوليات منفصلة.