الخلاصة

  • في مصافحة TLS كاملة، أتاح False Start للعميل إرسال بيانات بالمفاتيح الجديدة بعد Finished الخاص به بينما ظل Finished الخادم في طريق العودة.
  • بقيت المصافحة العادية مطلوبة؛ واحتاج التقديم إلى طلب من التطبيق وقوائم تشفير ضيقة وبروتوكول محدد وسياسة لفشل يصل بعد خروج البيانات.

سبق السجل الأول البرهان الأخير

وفق ترتيب RFC 5246، يعالج العميل شهادة الخادم وتبادل المفاتيح، ويرسل ChangeCipherSpec ثم Finished، وينتظر الرسالتين المقابلتين من الخادم. لا يطلق بيانات التطبيق عادة إلا بعد التحقق من Finished الآخر.

نقل False Start السجل الأول إلى وقت الانتظار. كان العميل قد اشتق المفاتيح الجديدة وأرسل برهانه. تحرك السجل المشفّر نحو الخادم بينما تحرك برهان الخادم النهائي في الاتجاه المعاكس.

يسمي RFC 7918 النجاح تحققاً بأثر رجعي. إذا وصل Finished صحيحاً، تصبح المصافحة العادية صالحة، ولا يختلف إلا التوقيت. لم تختف جولة الشبكة؛ استُخدم وقتها قبل معرفة نتيجتها.

اكتملت المفاتيح ولم يكتمل التأكيد

رأى العميل ServerHello ومجموعة التعمية والشهادة ومعلمات تبادل المفاتيح. يحمي Cipher Spec الجديد السجل، ولذلك ليست البيانات نصاً مكشوفاً ولا طلباً أرسل مع ClientHello بلا معرفة.

لكن Finished الخادم لم يؤكد بعد أن الطرف يملك الأسرار نفسها ورأى سجل المصافحة نفسه. إن غاب أو فشل، لم تُعتمد المصافحة. في التوقيت العادي كانت البيانات ستبقى؛ مع False Start خرجت بالفعل.

السؤال إذن ليس وجود التعمية فقط، بل نوع البيانات المسموح بكشفها قبل اكتمال آخر نتيجة توثيق.

قرار العميل لا امتداد إذن من الخادم

لم ينشئ False Start امتداداً يمنح به الخادم الإذن. عرّفه RFC 7918 تغييراً اختيارياً في سلوك العميل. الخادم المتوافق يتحمل وصول سجلات محمية قبل موضع معالجتها المعتاد.

قد تأتي معرفة التوافق من ملف تطبيق أو قناة خارجية؛ الصمت ليس موافقة. إعادة ضبط من وسيط أو خادم دليل على اختلاف توقع ترتيب الرسائل، لا على ضعف المفتاح.

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

قوائم السماح حاصرت الاختصار

قيّد RFC 7918 نسخة البروتوكول والتعمية المتماثلة وتبادل المفاتيح ومعلماته ونوع شهادة العميل. أوصى بعائلات DHE وECDHE المؤقتة التي توفر السرية المستقبلية. عند الشك لا يُستخدم False Start.

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

نجاح TLS في النهاية لا يكفي؛ يجب إثبات أن التركيبة الدقيقة كانت مخولة لعبور الحد في ذلك الوقت.

تعيّن اختيار لغة التطبيق قبل الكلام

يضع RFC 7301 ALPN داخل hello: يقترح العميل في ClientHello ويختار الخادم في ServerHello. قبل قرار False Start يعرف العميل أي بروتوكول سيفسر سجله.

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

يوقف الفشل المستقبل ولا يسترجع الماضي

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

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

لم يكن False Start هو 0-RTT

عرّف RFC 8446 TLS 1.3 و0-RTT مختلفاً. في الاستئناف قد تخرج البيانات بعد ClientHello بمفتاح مشتق من PSK سابق؛ لا تتمتع بسرية مستقبلية ولا بضمان ضد الإعادة بين الاتصالات.

يعمل False Start في مصافحة كاملة بمفاتيح جديدة وبعد Finished العميل. حدّه هو Finished الخادم غير المتحقق، لا إعادة بيانات PSK.

أنشأ RFC 8470 لـ HTTP الحقل Early-Data والرد 425 Too Early لإدارة إعادة 0-RTT، لا False Start. ويشترط RFC 9325 مواصفة تطبيق قبل 0-RTT وضبط ALPN واتساق الخوادم. المنهج متشابه والخصائص مختلفة.

المصادر والحدود

المصادر هي RFC 5246 وRFC 7301 وRFC 7918 وRFC 8446 وRFC 8470 وRFC 9325. لا تقيس الانتشار الحالي. لم يرسل False Start نصاً مكشوفاً، ولم يتجاوز الشهادة أو يستأنف جلسة أو يطلب امتداد خادم خاصاً.