TLS 1.3: ‏0-RTT والبيانات المبكرة واستئناف الجلسة

أُعيد تصميم مصافحة TLS 1.3 (‏RFC 8446، عام 2018) لتقليل زمن الاستجابة وإزالة المخلّفات القديمة. وتكتمل مصافحة TLS 1.3 الكاملة خلال 1-RTT: يرسل العميل ClientHello مع key_shares المدعومة (مفاتيح عامة مؤقتة لـ ECDH) في الدفعة الأولى؛ ويردّ الخادم برسالة ServerHello وkey_share الخاص به، وامتدادات مشفّرة، وشهادة، ورسالة Finished، وكلها في استجابة واحدة. ثم يرسل العميل رسالته Finished، ويمكنه إرسال بيانات التطبيق فورًا. وبالمقارنة مع مصافحة TLS 1.2 التي تستغرق 2-RTT، يؤدي ذلك إلى خفض زمن إعداد الاتصال الجديد إلى النصف.

يستخدم TLS 1.3‏ HKDF‏ (دالة اشتقاق المفاتيح المعتمدة على HMAC) مع جدول مفاتيح منظّم. بعد تبادل مفاتيح ECDHE، يُمرَّر السر المشترك إلى تسلسل هرمي: Extract(early_secret, DHE) -> handshake_secret؛ ثم Extract(handshake_secret, 0) -> master_secret. ومن هذه القيم، تستمد HKDF-Expand-Label مفاتيح منفصلة لحركة مصافحة العميل والخادم، وحركة التطبيق، والاستئناف. ويضمن هذا الفصل الواضح أن اختراق إحدى طبقات المفاتيح لا يؤثر في الطبقات الأخرى، وهو تحسّن مهم مقارنةً باشتقاق المفاتيح الأكثر ارتجالًا والقائم على PRF في TLS 1.2.

يستخدم استئناف الجلسة في TLS 1.3 مفاتيح مشتركة مسبقًا (PSKs) مشتقة من جلسات سابقة. بعد اكتمال المصافحة، يرسل الخادم رسالة NewSessionTicket التي تحتوي على هوية PSK وقيمة تذكرة (كتلة مشفّرة تحتوي على سر الاستئناف). وعند إعادة الاتصال، يضمّن العميل هوية PSK في ClientHello. وإذا تعرّف الخادم إليها، يستمد الطرفان مفتاح جلسة جديدًا من PSK بالإضافة إلى ECDHE جديد، وبذلك يتحقق الاستئناف خلال 1-RTT مع الحفاظ على السرية الأمامية. وللتذكرة مدة صلاحية قابلة للتهيئة (24 ساعة عادةً)، وينبغي تشفيرها باستخدام مفتاح دوّار من جانب الخادم.

يتيح TLS 1.3 إرسال البيانات المبكرة 0-RTT في الجلسات المستأنفة. ويستخدم العميل PSK من جلسة سابقة لتشفير بيانات التطبيق التي تُرسل في الدفعة الأولى، قبل أن يرسل الخادم أي إقرار. ويؤدي ذلك إلى إلغاء رحلة ذهاب وإياب واحدة عند الاتصال بخوادم سبق الوصول إليها، مما يوفر زمن استجابة يقترب من الصفر للاتصالات المتكررة. ويعلن الخادم دعم 0-RTT في NewSessionTicket من خلال امتداد early_data مع max_early_data_size. ويجب أن يمتلك الخادم آلية لقبول بيانات 0-RTT أو رفضها، ويشير إلى قبولها في EncryptedExtensions.

تفرض بيانات 0-RTT قيدًا أمنيًا جوهريًا: فهي معرّضة لهجمات إعادة التشغيل. إذ يستطيع مهاجم موجود على مسار الاتصال يلتقط الدفعة الأولى إعادة إرسالها إلى الخادم، مما يدفع الخادم إلى معالجة البيانات المبكرة مرة أخرى. وهذا أمر متأصل في التصميم، إذ إن الخادم لم يرسل أي رسالة بعد، ولذلك لا توجد عشوائية جديدة ساهم بها الخادم. وتشمل وسائل التخفيف: (1) تذاكر تُستخدم مرة واحدة (يبطل الخادم صلاحية التذكرة بعد استخدامها للمرة الأولى، باستخدام ذاكرة تخزين مؤقت موزّعة مثل memcached/Redis). (2) تذاكر محددة زمنيًا (رفض 0-RTT بعد نافذة قصيرة، مثل 5 ثوانٍ). (3) جعل العمليات غير قابلة للتأثر بالتكرار على مستوى التطبيق (السماح باستخدام 0-RTT فقط لعمليات آمنة مكافئة لطلبات GET).

تتمثل أقوى آلية للحماية من إعادة تشغيل 0-RTT في استخدام تذاكر جلسات أحادية الاستخدام. ويحتفظ الخادم بمخزن للتذاكر المستخدمة (وهو ذاكرة تخزين مؤقت موزّعة في عمليات النشر متعددة الخوادم). وعند وصول بيانات 0-RTT، يتحقق الخادم مما إذا كانت التذكرة قد شوهدت من قبل؛ فإذا كانت كذلك، يرفض البيانات المبكرة وينتقل إلى 1-RTT. أما إذا لم تكن كذلك، فيعلّم التذكرة على أنها مستخدمة ثم يعالج البيانات المبكرة. ولضمان الصحة، يجب أن تشترك جميع الخوادم في المجموعة في ذاكرة التخزين المؤقت للتذاكر المستخدمة. ويُعد Redis مع مدد TTL قصيرة (تطابق مدة صلاحية التذكرة) تطبيقًا شائعًا. ومن دون هذه الآلية، يكون 0-RTT غير آمن للعمليات غير القابلة للتكرار، مثل عمليات الدفع.

يفتقر استئناف PSK في TLS 1.3 من دون DHE إلى السرية الأمامية للجلسة المستأنفة؛ فإذا كُشف PSK لاحقًا، أمكن فك تشفير جميع حركة البيانات في الجلسات المستأنفة. وللحفاظ على السرية الأمامية، يدعم TLS 1.3 نمط PSK-with-DHE: إذ يتضمن ClientHello كلًا من هوية PSK وkey_share جديدًا. ويجمع الخادم بين PSK وناتج ECDHE لاشتقاق مفاتيح الجلسة. وحتى إذا كُشف PSK، تضمن مساهمة ECDHE بقاء حركة البيانات السابقة محمية. ويوصي RFC 8446 باستخدام PSK-with-DHE في جميع حالات الاستئناف التي تتطلب السرية الأمامية.

كان لدى TLS 1.2 أكثر من 300 تركيبة من مجموعات التشفير، وكان كثير منها غير آمن. ويقلل TLS 1.3 ذلك إلى 5 مجموعات تشفير، تستخدم جميعها AEAD: TLS_AES_128_GCM_SHA256، وTLS_AES_256_GCM_SHA384، وTLS_CHACHA20_POLY1305_SHA256، وTLS_AES_128_CCM_SHA256، وTLS_AES_128_CCM_8_SHA256. ويُتفاوض على تبادل المفاتيح والمصادقة بشكل منفصل عبر امتدادي supported_groups وsignature_algorithms. ويزيل هذا الفصل التعقيد التوافقي في TLS 1.2، ويضمن استخدام كل اتصال TLS 1.3 للتشفير الموثّق.

عمليًا، يكون 0-RTT أكثر فائدة لاتصالات HTTP/2 عندما يكرر العميل طلب GET (وهو آمن وغير قابل للتأثر بالتكرار) إلى خادم سبق الوصول إليه. وتطبق المتصفحات 0-RTT بحذر: إذ يفعّله Chrome لأساليب HTTP الآمنة، ولا تُرسل طلبات POST مطلقًا كبيانات 0-RTT. أما HTTP/3 عبر QUIC فيدمج TLS 1.3 أصلًا، إذ تعيد آلية 0-RTT في QUIC استخدام آلية TLS 1.3. وفي QUIC، يستعيد 0-RTT أيضًا معلمات النقل (التحكم في التدفق وحدود التدفقات) من الجلسة السابقة، مما يقلل النفقات الإضافية للإعداد إلى جانب تقليلها على مستوى TLS.

يتضمن TLS 1.3 آليات لمنع هجمات خفض الإصدار. ويحتوي الحقل العشوائي في ServerHello على قيمة مميّزة عند التفاوض على TLS 1.3: إذ تُضبط آخر 8 بايتات على قيمة ثابتة (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 عند الرجوع إلى TLS 1.2). ويتحقق العملاء القادرون على TLS 1.3 من هذه القيمة المميّزة عندما يتفاوض الخادم على TLS 1.2، وبذلك يكتشفون محاولات خفض الإصدار النشطة. بالإضافة إلى ذلك، تغطي تجزئة سجل Finished عملية المصافحة بأكملها، بما فيها التفاوض على الإصدار، ولذلك يمكن اكتشاف أي عبث. وتوفر قيم SCSV (Signaling Cipher Suite Values)، مثل TLS_FALLBACK_SCSV، إشارة منفصلة لخفض الإصدار في إصدارات TLS الأقدم.

يتطلب نشر TLS 1.3 الانتباه إلى عدة تفاصيل تشغيلية. فيجب تدوير مفاتيح تشفير تذاكر الجلسات (عادةً كل 24 ساعة) ومزامنتها عبر مجموعات الخوادم للسماح بالاستئناف على أي خادم. كما يجب الاحتفاظ بمفاتيح فك تشفير التذاكر القديمة طوال مدة صلاحية التذكرة لتجنب حالات فشل المصافحة غير المبررة. ويصبح OCSP stapling أكثر أهمية في TLS 1.3، إذ يلغي رحلة ذهاب وإياب واحدة للتحقق من حالة الشهادة. ويجب على موازنات التحميل تمرير ClientHello الخاص بـ TLS 1.3 من دون تعديل؛ إذ تتسبب بعض الأجهزة الوسيطة الأقدم في إتلاف الامتدادات غير المعروفة، مما يستلزم استخدام أوضاع التوافق.

لماذا تكون البيانات المبكرة 0-RTT معرّضة لهجمات إعادة التشغيل في TLS 1.3؟

يحقق TLS 1.3 مصافحات كاملة خلال 1-RTT واستئنافًا خلال 0-RTT عبر تذاكر جلسات PSK. ويستخدم اشتقاق المفاتيح HKDF مع جدول منظّم ينتج مفاتيح منفصلة لكل طبقة من طبقات حركة البيانات. وتلغي البيانات المبكرة 0-RTT رحلة ذهاب وإياب واحدة، لكنها معرّضة لإعادة التشغيل؛ ويمكن تخفيف ذلك باستخدام تذاكر أحادية الاستخدام وقصر 0-RTT على العمليات غير القابلة للتأثر بالتكرار. ويحافظ PSK-with-DHE على السرية الأمامية عند الاستئناف. ويقصر TLS 1.3 مجموعات التشفير على 5 خيارات من AEAD، مما يلغي التركيبات القديمة غير الآمنة. ويستخدم منع خفض الإصدار قيمًا مميّزة في الحقل العشوائي للخادم.