الخلاصة

  • أفصح wolfSSL 5.9.2 عن خلل عالي الخطورة في البُنى التي تدعم RPK: أمكن قبول مفتاح عام خام غير متفاوض عليه مكان X.509 وتجاوز تحقق السلسلة. يعامل الإصلاح X.509 كخيار افتراضي ويرفض اختلاف الشكل المستلم عن النوع المختار.
  • يعرّف RFC 7250 المفتاح العام الخام كنوع TLS مشروع وصريح يحمل بنية DER واحدة من SubjectPublicKeyInfo. تثبت المصافحة امتلاك المفتاح الخاص المقابل، لكن SPKI لا تحمل جهة إصدار أو موضوعاً موقعاً أو مدة صلاحية أو دوراً تطبيقياً.
  • يلزم لقبول RPK بأمان دليلان مستقلان: أن الطرفين اختارا هذا النوع فعلاً، وأن سجلاً خارجياً حديثاً ما زال يربط SPKI بالاسم أو الخدمة أو الجهاز أو الدور المقصود. نجاح الاتصال وحده لا يثبت أياً منهما.

عندما اختار المدخل أداة الحكم

صنف بيان الإصدار 5.9.2 المشكلة CVE-2026-55960 بدرجة High. عند بناء المكتبة مع HAVE_RPK كان من الممكن أن يصل مفتاح خام من دون تفاوض على نوعه ثم يُعامل كبديل لشهادة X.509. ولأن المفتاح الخام لا يحتوي سلسلة، لم ينفذ مسار التحليل تحقق الثقة الذي كان يفترضه مسار الشهادة.

النطاق محدد: دعم RPK معطل افتراضياً في البناء المستقل، لكنه يدخل مع --enable-all. لا تقدم المصادر تعداداً للاستغلال أو نطاقاً كاملاً للإصدارات المتأثرة. لذلك لا يصح تحويل الحالة إلى تقدير انتشار. ما تثبته هو انتقال سلطة غير مشروع: البيانات الواردة اختارت نظام تحقق مختلفاً عن النظام الذي سمح به التفاوض.

أعاد الإصلاح ترتيب القرارات. إذا لم يُتفاوض على بديل فالمتوقع X.509. يقارن العميل شكل اعتماد الخادم بالنوع المختار، ويجري الخادم المقارنة المقابلة لاعتماد العميل. ينتهي أي اختلاف، بما فيه RPK غير المتفاوض عليه، إلى UNSUPPORTED_CERTIFICATE. ويوثق PR 10702 اختبارات في الاتجاهين.

القضية أعمق من سلامة parser. قدرة المكتبة على قراءة SPKI لا تمنحها حق اعتمادها. يجب أولاً اختيار عقد الثقة في المصافحة، ثم لا يدخل إلى أداة التحقق إلا الشكل الذي سمح به العقد.

المفتاح الخام ليس شهادة ناقصة

يسجل RFC 7250 قيمة Raw Public Key بالرقم 2 ويحدد امتدادين لنوع اعتماد العميل والخادم. يعلن كل طرف ما يستطيع إرساله أو معالجته، ثم يُختار نوع مشترك. لا مكان لتخمين صامت إذا لم يوجد اتفاق.

عند اختيار RPK تحمل رسالة Certificate بنية DER واحدة من SubjectPublicKeyInfo: معرف الخوارزمية ومعلماتها إن وجدت وبتات المفتاح. هذه هي البنية الموجودة داخل X.509، لكن بقية الشهادة غير موجودة.

يحافظ RFC 8446 على RPK في TLS 1.3 من خلال RawPublicKey(2). إذا تم التفاوض عليه، لا تحتوي certificate_list على أكثر من مدخل SPKI واحد. ويثبت المرجع أيضاً القاعدة الافتراضية: النوع X.509v3 ما لم يتم الاتفاق صراحة على غيره.

لذلك غياب السلسلة طبيعي عندما اختير RPK، وليس عيباً ينبغي ترقيعه. لكن SPKI سليمة البنية لا يجوز أن تحل محل X.509 عندما لم تُختر. صلاحية الترميز وسلطة النوع اختباران مختلفان.

التوقيع يثبت الحيازة ولا يسمي الجهاز

في TLS 1.3 تربط CertificateVerify التوقيع بنص المصافحة وتثبت أن الطرف يملك المفتاح الخاص المقابل. ثم تؤكد Finished حالة المصافحة. النتيجة قوية: هذا الطرف تحكم بالمفتاح في هذا السياق.

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

لهذا يشترط RFC 7250 آلية خارج المسار تربط المفتاح بالكيان الذي يقدمه، ويشترط فحص حالة الربط. البصمة التي زُرعت في المصنع أو سجل TLSA أو مفتاح أول اتصال هي حقيقة تاريخية. قد تنتهي بعد التدوير أو التسريب أو إعادة التخصيص أو السحب.

يجب أن يتضمن سجل الربط الهوية والدور، نطاق host/service، SPKI الدقيقة، صاحب قرار التسجيل، وقت النفاذ والانتهاء، المفتاح السابق واللاحق، حالة السحب، قناة التوزيع، والدليل على أن نقاط التحقق ترفض المفتاح المتقاعد.

الواجهات البرمجية تكشف مكان القرار الخارجي

تطلب وثائق wolfSSL تمكين RPK وضبط أنواع الاعتماد وتوفير callback يتحقق من المفتاح خارج TLS. ينجح مثال TLS 1.3 المتبادل مع GnuTLS في إنشاء الاتصال، لكنه يبلغ أن الطرف غير متحقق منه حتى تعمل هذه الآلية. التوافق في البروتوكول لا يساوي هوية معتمدة.

يوفر GnuTLS نموذجاً آخر: البحث عن مفتاح محفوظ بواسطة host وservice، والتمييز بين غياب السجل وعدم تطابق المفتاح، وإضافة انتهاء أو backend مخصص. كما يوضح أن تحقق الشهادات المعتاد لا يستطيع إثبات RPK بلا جسم شهادة؛ يلزم تطابق خارج المسار أو قاعدة استمرارية مثل TOFU.

هذه API نقاط تنفيذ وليست مصدراً للشرعية. يبقى السؤال: من سجل القيمة الأولى، ومن وقّع التحديث، وهل نُفذ callback في هذه الجلسة، وأي صلاحية فُتحت بعد النجاح؟

DANE والبرمجيات الثابتة: ربط واحد بسرعتين

DANE خيار خارجي ذكره RFC 7250. يتيح RFC 6698 لسجل TLSA المحمي بـDNSSEC اختيار SPKI ومطابقتها كاملة أو بملخص. بذلك يرتبط اسم خدمة بمادة المفتاح في نطاق سلطة DNS.

لا يصبح السجل نافذاً إلا عندما يتحقق العميل من DNSSEC ويفسر usage وselector وmatching type ويقارن الكائن الصحيح. النشر وحده ليس قرار قبول.

يرسم RFC 7671 تدويراً موزعاً: نشر الربط الجديد مسبقاً، انتظار انتهاء caches القديمة، نشر المفتاح أو الشهادة المقابلة، ثم إزالة الروابط المتقادمة. أثناء الانتقال قد ترى نقاط مختلفة أجيالاً مختلفة على نحو صحيح، ولهذا يجب معرفة الجيل المرئي لكل محقق.

في الأجهزة المقيدة يعمل الزمن عبر firmware. يصف RFC 7925 تزويد الجهاز بمفتاح الخادم أو ملخصه قبل الاتصال، ويرى RPK مدخلاً للتشفير العام من دون عبء الشهادة الكامل. جهاز يعيش سنوات طويلة يظل بحاجة إلى مسار تحديث آمن. تقليل حجم المصافحة ينقل عمل الهوية إلى دورة التزويد ولا يلغيه.

سبع حقائق خلف إشارة نجاح واحدة

افصل السياسة المضبوطة، قائمة الأنواع المعروضة، النوع المختار، الشكل المستلم، إثبات الحيازة، مصدر الربط الخارجي وإصداره وحداثته، وأخيراً قرار التطبيق والعملية المسموحة.

قد تخفي tls_success واحدة مفتاحاً غير متفاوض عليه، ربطاً قديماً، callback لم يعمل أو دوراً أوسع من السجل. وقد يكون رفض مفتاح صحيح حسابياً هو النتيجة الآمنة لأن نوعه لم يؤذن له.

توفر أولوية الشيفرة العاملة لدى Heng Lu عدسة محدودة ومفيدة. يحدد RFC الدلالة، وتسجل IANA الأرقام، وينشر DNS أو نظام التهيئة الادعاء؛ لكن نقطة القبول الحية هي التي ترفض النوع الخاطئ وتقرأ الربط الساري وتقيد الامتياز. غيّر إصلاح 2026 هذا الفيتو التنفيذي.

حدود الدليل

تثبت المصادر طبيعة الخلل وشرط البناء والإصلاح. لا تثبت استغلالاً ولا عدداً من الأنظمة ولا كامل نطاق الإصدارات. كما لا تثبت أن RPK أضعف بطبيعته من X.509.

يمكن لمفتاح خام متفاوض عليه ومرتبط بسجل محمي أن يناسب شبكة مغلقة أو جهازاً محدوداً. ويمكن لـX.509 أن يفشل بسبب تحقق مسار أو اسم سيئ. القاعدة هي ألا يرث اعتماد قبول اعتماد آخر بينما يفلت من قواعده.

Sources