الخلاصة

  • يسمح draft-ietf-tls-pake-02 للخادم بمحاكاة مشاركة PAKE عندما لا يجد سجل تسجيل، لذلك لا يثبت ServerHello وجود الحساب ولا صحة كلمة المرور.
  • لا تمنع المحاكاة تعداد المستخدمين إلا إذا توحدت أيضاً مدة المعالجة والتنبيه واستهلاك الموارد والسجلات والحدود؛ ويظل Finished وشهادة الخادم وتفويض التطبيق أدلة منفصلة.

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

أخفت الرسالة الحساب وكشفته العمليات المحيطة بها.

نُشرت المراجعة 02 من مشروع TLS PAKE في 6 يوليو 2026 وتنتهي في 7 يناير 2027. هي Internet-Draft معلوماتية نشطة في مجموعة TLS، وليست RFC أو سجلاً نهائياً أو تقرير تنفيذ أو تدقيقاً أمنياً. ويقر النص بأن التحليل الأمني المهم لم يكتمل بعد.

كلمة المرور ليست PSK عادية

يفترض binder الخاص بـ TLS 1.3 أن المفتاح المشترك عالي العشوائية. إذا استُخدمت كلمة مرور بشرية مباشرة، يستطيع المراقب اختبار التخمينات خارج الاتصال. تقترح الوثيقة امتداد pake الذي يحمل رسائل تبادل مفاتيح مصادق بكلمة مرور، ثم يضم سره إلى تبادل TLS المؤقت العادي في جدول المفاتيح.

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

هذه الحقيقة هي بداية نموذج الأدلة: دعم المخطط، وجود السجل، امتلاك كلمة المرور، اكتمال Finished، وهوية الشهادة ليست حالة واحدة.

الاستجابة المحاكية مصممة لتبدو ناجحة مؤقتاً

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

الغرض أن يعمل الخادم ككاشف لكل زوج هوية/كلمة مرور معاً، لا كدليل مجاني على وجود الهوية. لذلك لا يجوز عد اختيار المخطط أو مشاركة ServerHello ضمن «المستخدمين المعروفين».

لكن التشابه على السلك شرط واحد. استعلام قاعدة التسجيل قد يلمس قرصاً في حالة ويصيب cache في أخرى. مسار الخطأ قد يستهلك CPU مختلفاً أو يطلق alert أبكر أو يستخدم bucket منفصلاً للحد من المحاولات. كل فرق يصبح قناة تعداد.

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

Finished هو حد مصادقة العميل

يدخل سر PAKE مع (EC)DHE إلى جدول مفاتيح TLS، وتربط رسائل Finished المعرفة بالـ transcript. لا يكون العميل مصادقاً لدى الخادم قبل التحقق من Finished الخاص به.

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

بعد النجاح، يظل المعنى محدوداً: امتلك الطرف مادة المفتاح لهذه الجلسة. لا يثبت ذلك الهوية القانونية أو سلامة الجهاز أو صحة التسجيل أو صلاحية تنفيذ عملية مالية. التفويض قرار تالٍ يملكه التطبيق.

هوية PAKE ليست SNI ولا الشهادة

تنص الوثيقة على أن server_identity في PAKE منفصلة عن SNI. الأولى تدخل في سياق التسجيل، والثانية تساعد في توجيه الاتصال واختيار الخدمة. وإذا أرسل العميل signature_algorithms، يجب على الخادم المختار لـ PAKE تقديم Certificate وCertificateVerify، فتضاف دعوى هوية أخرى.

قد تفرض المؤسسة تطابق الأسماء، لكن هذا التوافق سياسة محلية. لا يصنعه البروتوكول. يجب أن يحفظ receipt كل قيمة ونتيجة تحقق وقاعدة ربط على حدة.

مصطلح «مصادقة متبادلة» دون وصف النمط قد يخفي أن بعض الخدمات اعتمدت PAKE وحده وبعضها طلب شهادة أيضاً. كما لا تحول الشهادة الصحيحة هوية PAKE إلى حساب مخول.

PAKE الخارجي يحتاج دليلاً يربط مرحلتين

المخططات الداخلية تضع تبادلها في ClientHello وServerHello. المخطط الذي يحتاج رسائل أكثر يعمل قبل TLS، ثم تُستورد نتيجته كـ PSK وفق RFC 9258.

نجاح TLS اللاحق يثبت معرفة المفتاح المستورد. لا يثبت تلقائياً هوية الطرف في التبادل السابق أو صحة channel binding أو أن النتيجة لم تُربط باتصال متزامن آخر.

يفصل RFC 9258 المفتاح حسب البروتوكول وKDF والسياق، لكنه لا يراقب ما إذا كان التطبيق قد ملأ السياق الصحيح. يجب الاحتفاظ بربط محدود الخصوصية بين hash الـ transcript السابق وهوية الاستيراد والاتصال الذي استهلكها.

حماية الحركة بعد-كمية لا تكفي لكلمة المرور

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

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

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

التسجيل سلطة سابقة للمصافحة

تفترض PAKE كلمة مرور أو verifier وهوية وsalt ومعلمات جرى إعدادها مسبقاً. لا تحدد المسودة من أثبت الشخص عند التسجيل أو من وافق على reset أو كيف تُلغى السجلات القديمة.

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

لا ينبغي تحميل Finished ما لا يقوله. قوته في إثبات امتلاك سر مرتبط بجلسة محددة، لا في إصلاح حوكمة الهوية.

نجاح الحماية يُقاس بعدم قدرة المهاجم على التفريق

القيمة التشغيلية للمحاكاة ليست أن الخادم أعاد bytes صحيحة، بل أن المراقب لا يستطيع التمييز بين «هوية مجهولة» و«كلمة مرور خاطئة» قبل اختبار الزوج كاملاً.

يتطلب ذلك تعاون TLS وقاعدة التسجيل والحد من الإساءة والمراقبة. إذا كشف أي منها النتيجة، ينهار الادعاء بينما يبقى handshake مطابقاً للمواصفة ظاهرياً.

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

المصادر