الخلاصة

  • يعرّف RFC 9645 مجموعات YANG قابلة لإعادة الاستخدام لهوية العميل والخادم، ولمصادقة الطرف المقابل، ولمعلمات Hello وسياسة البقاء. لكنه يقدم حدًا أدنى مشتركًا للضبط، لا سجلًا كاملًا لكل جلسة.
  • وجود شهادة أو مفتاح عام خام أو PSK في الضبط يثبت أن المشغّل أجاز احتمالًا. ولا يثبت ما طلبه الطرف المقابل، أو مادة الهوية التي قُدمت، أو نجاح التحقق، أو استئناف الجلسة، أو الحساب الذي اعتمده التطبيق.
  • يحتاج الادعاء القابل للدفاع إلى إيصال يربط إصدار النموذج والضبط بفرع المصادقة المنفذ، وهوية الطرف، ونتيجة التحقق، ومصادقة العميل الاختيارية، وصلاحية التطبيق ونتيجة العملية.

الفرق بين التفويض والتنفيذ

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

لا يدّعي RFC 9645 أنه يحل هذه الفجوة. فهو يعرّف ietf-tls-common وietf-tls-client وietf-tls-server إلى جانب وحدة تعداد مجموعات التشفير التي تديرها IANA. تركز مجموعات العميل والخادم على TLS نفسه، وتترك العنوان والمنفذ وطريقة إنشاء الاتصال للنماذج المستهلكة. ويصف النص النموذج العام بأنه «القاسم المشترك الأدنى» لا وصفًا كاملًا لكل وظائف TLS.

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

لكل فرع هوية معنى إثباتي مختلف

تتيح بنية الهوية أربع فئات رئيسية: شهادة، مفتاح عام خام، PSK لـ TLS 1.2، وPSK خارجي لـ TLS 1.3. ليست هذه مجرد صيغ مختلفة لحقيقة واحدة.

يعتمد فرع الشهادة على السلسلة واسم المرجع والوقت واستخدام المفتاح وخوارزمية التوقيع ومرساة الثقة والسياسة المحلية. أما المفتاح العام الخام فلا يحمل دلالة سلسلة الشهادات، وغالبًا ما يعتمد على مطابقة دقيقة مع مفتاح موثوق. ويعمل PSK في TLS 1.2 وفق دلالات الإصدار الأقدم. ويضيف PSK الخارجي في TLS 1.3 هوية خارجية وhash وسياقًا ومعلمات هدف اختيارية.

يحذر RFC 9257 من أن معرّف PSK قد يكون ظاهرًا وقابلًا للربط بين الاتصالات، وأن أعضاء مجموعة تتشارك السر يمكنهم انتحال بعضهم بعضًا. ويميّز RFC 9258 المفتاح المستورد المرتبط بسياق عن المفتاح الخالي من السياق. لذلك قد يثبت نجاح PSK عضوية مجموعة، من دون أن يحدد جهازًا أو شخصًا بعينه.

ينبغي للإيصال أن يسجل الفرع، وفئة PSK، ووجود السياق، وبصمة محمية للمادة التي حُمّلت فعلًا، من دون تسجيل السر نفسه. إن اختزال ذلك إلى «هوية TLS مضبوطة» يمحو أساس الإسناد.

مصادقة الخادم ليست مصادقة العميل

يفصل نموذج العميل بين client-identity وserver-authentication. وهوية العميل اختيارية لأن طبقة أعلى قد تنفذ المصادقة. وحتى عند ضبطها، لا تُرسل على مستوى TLS إلا عندما يطلبها الخادم أثناء إنشاء الجلسة.

ويفصل نموذج الخادم كذلك بين server-identity وحاوية client-authentication الاختيارية. عند غياب الأخيرة لا ينبغي للخادم طلب بيانات اعتماد العميل. وعند وجودها تصبح شهادات CA والشهادات النهائية الدقيقة والمفاتيح الخام وآليات PSK إمكانات إضافية لقبول العميل.

لهذا فإن عبارة «mTLS مفعّل» شديدة الاختصار. فقد تعني القدرة على الطلب لا حدوثه. وقد يحدث الطلب من دون استجابة، أو تصل الاستجابة ويفشل التحقق، أو ينجح التحقق ثم يرفض التطبيق إنشاء principal، أو ينشئه من دون منحه العملية المطلوبة.

يجب فصل القدرة والطلب والتقديم والتحقق وربط الهوية والتفويض. من دون هذا الفصل تتحول أسباب مختلفة إلى خطأ غامض واحد.

الاستئناف يغيّر طبيعة الدليل

يحافظ RFC 9846، وهو مواصفة TLS 1.3 الحالية وقت هذا البحث، على فصل الإصدار وخوارزميات التوقيع والمجموعات وkey shares وهويات PSK. يختار الخادم PSK ومجموعة تشفير متوافقين، ويتحقق من binder يربط المفتاح بنص handshake الحالي.

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

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

لذلك ينبغي تسجيل ما إذا كان المسار كاملًا أو مستأنفًا أو استخدم بيانات مبكرة، مع أصل PSK وحالة سياقه، من دون كشف مادة المفتاح.

الإصدار ومجموعة التشفير لا يحددان الهوية

تمكّن hello-params-grouping من ضبط الحد الأدنى والأقصى لإصدار TLS وقائمة مرتبة من مجموعات التشفير. وتصف حالة الخوارزميات المدعومة قدرة التنفيذ. هذه حقائق ضرورية عن القناة المشفرة، لكنها لا تحدد الطرف.

يحذر سجل IANA من ضعف الخوارزميات مع الزمن ومن أن التسجيل ليس توصية. كما تختلف دلالة مجموعات TLS 1.3 عن دلالة TLS 1.2. يقدم RFC 9325 إرشادات النشر الآمن، بينما يفرض RFC 9852 دعم TLS 1.3 للبروتوكولات الجديدة ضمن نطاقه. قد يبقى الاسم قابلًا للتمثيل بينما يتغير قرار استخدامه.

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

الحد الأدنى من إيصال مسار المصادقة

يفصل RFC 8342 بين الضبط المقصود والحالة التشغيلية، ويقيد RFC 8341 من يستطيع تغيير العقد الحساسة، ويقدم RFC 9641 وRFC 9642 مراجع truststore وkeystore التي يعيد RFC 9645 استخدامها. تثبت كل طبقة حقيقة محددة ولا تنتج تلقائيًا حقيقة الطبقة التالية.

قد يُحل مرجع keystore ولا يُختار. وقد يوجد truststore من دون شهادة واردة. وقد يصبح الضبط فعالًا على listener لم تصله الجلسة. وقد يتحقق TLS من مفتاح يرفض التطبيق ربطه بحساب. وقد يملك الحساب صلاحية بينما تفشل العملية نفسها.

يوفر فصل Heng Lu بين السلطة الرمزية والواقع التنفيذي ترتيبًا واضحًا: النموذج يحكم المفردات، وإدارة التغيير تحكم النية، وحزمة TLS تنفذ فرعًا، والتطبيق يمنح المعنى والنتيجة.

يحتاج الإيصال الأدنى إلى:

  • إصدار RFC/YANG وfeatures وdeviations والنموذج المستهلك؛
  • إصدار الضبط المطبق ومصدر datastore والموافق ووقت التفعيل؛
  • فرع الهوية ومراجع keystore/truststore التي حُلّت فعلًا؛
  • بصمات أو إصدارات محمية لبيانات الاعتماد والثقة المحملة؛
  • معرّف ربط للجلسة وطوابع زمنية موثوقة؛
  • إصدار TLS ومجموعة التشفير المتفاوض عليهما بمعزل عن نمط الهوية؛
  • مسار كامل أو مستأنف أو early data وأصل PSK وسياقه؛
  • الهوية المقدمة وطريقة التحقق ومدخلاته ونتيجته وعدم اليقين؛
  • طلب مصادقة العميل واستجابته والتحقق وprincipal الناتج؛
  • اكتمال handshake والتنبيهات والمحاولات والfallback؛
  • تفويض التطبيق والعملية وشرط القبول والنتيجة؛
  • الحقول غير المرصودة والجهة المخولة اعتماد العبارة النهائية.

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

المصادر

  1. المواصفة الأولية الدنيا
  2. طبقات الواقع والسلطة الرمزية
  3. أولوية الشيفرة العاملة
  4. سجل وثيقة RFC 9645
  5. صفحة معلومات RFC 9645
  6. RFC 9645 بصيغة HTML
  7. RFC 9645 نصًا
  8. RFC 9645 بصيغة XML
  9. تصحيحات RFC 9645 المضمنة
  10. معلمات TLS لدى IANA
  11. وحدة YANG لمجموعات تشفير TLS
  12. RFC 9641: نموذج truststore
  13. RFC 9642: نموذج keystore
  14. RFC 9846: TLS 1.3 الحالي
  15. RFC 9852: TLS 1.3 للبروتوكولات الجديدة
  16. RFC 9325: النشر الآمن لـ TLS
  17. RFC 9257: إرشادات PSK الخارجي
  18. RFC 9258: استيراد PSK الخارجي
  19. RFC 8341: التحكم في الوصول إلى الضبط
  20. RFC 8342: معمارية مخازن بيانات إدارة الشبكة