الخلاصة

  • يثبت Finished سجل المصافحة الحالية باستعمال السر المتفق عليه؛ ولا تدخل بيانات التطبيق السابقة لإعادة التفاوض تلقائياً في ذلك الإثبات.
  • تحمل RFC 5746 قيم verify_data السابقة لتربط المصافحة الجديدة بسابقتها. وتظل هوية الطلب وحدوده وتفويضه وتثبيته ونتيجته بحاجة إلى إيصالات أخرى.

هوية جديدة فوق بداية قديمة

يحمل الاتصال بيانات محمية بالفعل. تصل ClientHello أخرى، وقد يطلب الخادم شهادة عميل، وتتغير المفاتيح، وينجح Finished. من منظور TLS، انتهت المصافحة كما ينبغي.

في RFC 5246 تُشتق verify_data من السر الرئيسي ورسائل المصافحة. نجاحها يعني أن الطرفين اتفقا على سجل التفاوض وحالة المفاتيح. لكنه لا يضم بيانات التطبيق العادية التي سبقت المصافحة الثانية.

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

استمرار المقبس لا يعني استمرار السلطة

يميز TLS 1.2 بين الحالة الحالية والحالة المعلقة. تجهز المصافحة الخوارزميات والأسرار، ثم يفعل ChangeCipherSpec الحالة الجديدة، ويختبر Finished النتيجة تحت الحماية الجديدة.

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

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

RFC 5746 تجعل العودة إلى السابق قابلة للفحص

أضاف Secure Renegotiation امتداد renegotiation_info والقيمة TLS_EMPTY_RENEGOTIATION_INFO_SCSV. في المصافحة الأولى يعلن الطرفان الدعم بقيمة اتصال معاد التفاوض فارغة. وفي إعادة التفاوض يحمل الامتداد verify_data السابقة للعميل والخادم.

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

لكن دعم الامتداد لا يثبت تنفيذه. قد تفهمه المكتبة بينما تمنع السياسة إعادة التفاوض، وقد يظهر SCSV من دون مصافحة ثانية. يجب فصل قدرة التنفيذ، والسياسة المحملة، والإشارة، واستجابة الطرف، والحدث الفعلي، ونتيجة مقارنة القيم القديمة.

إصلاح TLS لا يرسم حدود طلب التطبيق

لا تقول RFC 5746 ما العمل بأمر بدأ قبل تغير الهوية. يمكن التخلص منه، أو إكماله بالهوية القديمة، أو طلب رسالة كاملة جديدة. القرار يتبع بنية التطبيق وسياسة التفويض.

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

تتيح channel bindings في RFC 5929 للطبقات الأعلى الإشارة إلى خصائص القناة، لكن إنتاج قيمة الربط واستخدام التطبيق لها والتحقق منها وربطها بالعملية أربع خطوات مختلفة.

EMS يصل علاقة أخرى

يشتق Extended Master Secret في RFC 7627 السر الرئيسي من hash لسجل المصافحة، ويعالج مشكلات session hash وtriple handshake. وهو لا يحل محل RFC 5746.

يربط EMS السر بمصافحته، بينما تربط Secure Renegotiation المصافحة الجديدة بالاتصال السابق. جمعهما في علامة «TLS مقوى» يمحو نوع العلاقة التي جرى التحقق منها.

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

أزال TLS 1.3 الآلية ولم يزل الأسطول

لا يدعم TLS 1.3 إعادة التفاوض، فتختفي هذه الوصلة المتحركة. لكن تفعيل 1.3 لا يثبت خروج TLS 1.2 من كل نقطة. قد يستعمل الوكيل 1.3 مع العميل و1.2 مع المصدر، أو يبقى fallback محملاً.

تجمد RFC 9851 العمل العادي على خصائص TLS 1.2 الجديدة، لكنها لا توقف أي listener. يحتاج إثبات الهجرة إلى مخزون، وسياسة محملة، ومصافحات مرصودة، ومالك لكل اعتماد، واختبارات خدمة تمر في الطريق نفسه.

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

هذا السجل تحليل تشغيلي من BTW، لا صيغة سجل تفرضها RFC 5246. وهو يمنع إيصالاً تشفيرياً قوياً من ادعاء سلطة على قرار لم يره.

المصادر