تأكيد مصافحة QUIC هو محطة في دورة المفاتيح، وليس جاهزية للتطبيق

الخلاصة

• اكتمال مصافحة QUIC محلي ويعتمد على منظور كل نقطة نهاية، ولا يحدث بالضرورة في الوقت نفسه لدى الطرفين.
• تؤكد HANDSHAKE_DONE، أو ACK مؤهل باستخدام 1-RTT لدى العميل، انتقالاً في البروتوكول وتستدعي التخلص من مفاتيح Handshake.
• يجب ربط التأكيد بأدلة 0-RTT وبنتيجة التطبيق قبل إعلان جاهزية الخدمة.

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

تعرّف RFC 9001 اكتمال المصافحة من منظور محلي. تصبح المصافحة مكتملة عندما تكون حزمة TLS المحلية قد أرسلت رسالة Finished وتحققت من رسالة Finished الخاصة بالطرف الآخر. ولا يلزم أن تتحقق هذه الحالة في الوقت نفسه عند نقطتي النهاية. لذلك ينبغي أن تسجل المراقبة من رأى الانتقال وبأي دليل، لا أن تضع علامة زمنية واحدة توحي بتزامن الطرفين.

يختلف التأكيد بحسب الدور. عند الخادم، تُؤكَّد المصافحة عند اكتمالها، ويجب على الخادم إرسال HANDSHAKE_DONE فور اكتمالها. عند العميل، يؤدي استلام HANDSHAKE_DONE إلى التأكيد. ويمكن للعميل أيضاً استنتاج التأكيد من ACK يغطي حزمة أرسلها باستخدام مفاتيح 1-RTT. ولا يسمح RFC 9000 إلا للخادم بإرسال HANDSHAKE_DONE. فالـframe يخبر العميل بأن الخادم استلم حزمة Handshake الخاصة بالعميل وعالجها، لكنه ليس رداً من التطبيق.

تكمن النتيجة المباشرة في دورة حياة المفاتيح. عند تأكيد المصافحة، يجب على نقطة النهاية التخلص من مفاتيح Handshake، وبذلك تنتهي الحقبة التشفيرية الخاصة بها. غير أن هذا لا يثبت انتهاء تفاوض بروتوكول التطبيق، ولا وصول الطلب إلى كود التطبيق، ولا صحة التخزين الدائم، ولا جاهزية خدمة خلفية أو خدمة تفويض.

مفاتيح Initial تخضع لدليل مختلف. يتخلص العميل منها عندما يرسل أول حزمة Handshake، بينما يتخلص الخادم منها عندما يعالج بنجاح أول حزمة Handshake. التخلص من Initial ليس هو تأكيد المصافحة، ولا يجوز دمجه مع التخلص من Handshake. إن جمع الأحداث المختلفة في سجل واحد يخفي الحدود التي يحتاج إليها التشخيص.

قرار 0-RTT مستقل كذلك. يقبل الخادم 0-RTT عندما يضمّن امتداد early_data في EncryptedExtensions، ويرفضه عندما يحذف الامتداد. عند الرفض، لا يجوز للخادم معالجة حزم 0-RTT، ويجب على العميل إعادة ضبط جميع التدفقات، بما فيها حالة التطبيق المرتبطة بها. لا تستطيع HANDSHAKE_DONE اللاحقة تحويل البيانات المرفوضة إلى عمل مقبول.

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

حتى دليل ACK باستخدام 1-RTT يبقى محدوداً. فإذا غطى أقل رقم حزمة 1-RTT أرسله العميل، فإنه يحقق شرط التأكيد الذي تحدده RFC 9001. لكنه لا يثبت استهلاك التطبيق للبيانات، ولا التخزين الدائم، ولا نجاح التفويض، ولا اكتمال المعاملة التجارية. إنه إيصال لحالة تشفيرية، وليس إيصالاً لنتيجة تجارية.