الخلاصة

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

اتجاهان بميزانيتين منفصلتين

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

تظهر الحاجة إلى ذلك في الاتصالات الطويلة. خوارزميات التشفير الموثق AEAD لها حدود استخدام مرتبطة بكمية البيانات المحمية تحت مفتاح واحد وبهوامش السرية والسلامة الاحتمالية. نجاح المصافحة لا يمنح المفتاح عمراً بلا نهاية. لذلك يوصي RFC 8446 بالتحديث قبل بلوغ الحدود المعنية، ويطلب RFC 9325 من التطبيقات ذات الجلسات الطويلة التفكير في سياسة تجديد مفاتيح الجلسة.

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

رسالة التحديث تعبر تحت حماية الجيل القديم

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

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

عندما تحمل الرسالة update_not_requested يتوقف الأثر عند اتجاه الإرسال ذاك والاستقبال المناظر له. أما update_requested فتطلب من الطرف الآخر إرسال KeyUpdate خاص به مع update_not_requested. الرسالة الثانية هي التي تنقل الاتجاه العكسي؛ الأولى لا تستبدل المفتاحين معاً بصورة سحرية.

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

الحذف يغلق الماضي ولا يقطع المستقبل

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

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

وهنا يفترق سببان للتغيير. الاقتراب من حد استخدام AEAD يستدعي جيلاً جديداً. الاشتباه في تسرب السر الجاري يستدعي إيقاف الاتصال وإجراء مصافحة جديدة تأتي بمادة سرية جديدة. لوحة المراقبة التي تسمي الحدثين «تدويراً ناجحاً» قد تعرض لوناً أخضر فيما يستمر الاختراق نفسه.

لماذا قبله HTTP/2 ورفض آلية هوية أوسع

قد يحمل اتصال HTTP/2 طلبات متزامنة كثيرة. تغيير الهوية المصادق عليها وسط هذا الاتصال يخلق غموضاً حول الطلبات التي تنتمي إلى كل هوية. لذلك يمنع RFC 9113 المصادقة اللاحقة للمصافحة في TLS 1.3 عند استخدام HTTP/2.

لكن الوثيقة تسمح بـ KeyUpdate، لأن تبديل جيل حماية السجلات لا يغير مباشرة هوية طلب HTTP أو صلاحياته. تستمر المسارات، ويتقدم اتجاه تشفيري تحتها. ضيق سلطة العملية هو سبب ملاءمتها للتعدد، لا استثناء عام لكل تغيير بعد المصافحة.

أما QUIC فرسم حدوداً أخرى. يمنع RFC 9001 رسائل TLS KeyUpdate داخل QUIC. وبما أن الرزم قد تصل بغير ترتيب، يستخدم QUIC بت Key Phase وقواعد إقرار خاصة به. الغاية المشتركة لا تجعل آلية TLS المبنية على سجل مرتب صالحة لكل نقل.

مفتاح جديد بلا ادعاء بداية جديدة

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

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

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

يعتمد المقال على RFC 8446 وRFC 9001 وRFC 9113 وRFC 9325. لا تثبت هذه الوثائق نسبة الانتشار الحالية أو إعدادات المكتبات الافتراضية أو زمناً موحداً للتحديث.