الخلاصة

  • يغلق close_notify في RFC 9846 اتجاه إرسال واحداً في TLS إغلاقاً منتظماً، ويمنح المتلقي حداً مشفراً يكشف خطر الاقتطاع. لكنه لا يؤكد أن التطبيق حلل الطلب أو حفظه أو أحدث أثره أو سوّاه.
  • يجمع سجل الإغلاق السليم بين آخر سجل TLS مقبول والتنبيه، وبين معرّف معاملة ونتيجة موثوقة وقاعدة إعادة محاولة محفوظة بصورة مستقلة. لا تتحول مجاورة الحدثين زمنياً إلى سلطة لإثبات أحدهما بالآخر.

لنتخيل عميلاً للدفع يرسل تعليمة، ويفرغ مخزن الإرسال، ثم يتلقى close_notify من الخادم. تبلغ مكتبة TLS التطبيق بنهاية البيانات من غير خطأ في البروتوكول. إذا كتب العميل عندئذ «تم الدفع»، فما الدليل الذي يجيز هذه النتيجة؟ ليس تنبيه الإغلاق. ربما قرأ الخادم البايتات ورفض التعليمة، أو حللها ثم تعطل قبل التثبيت، أو ثبّتها وفقد الرد وحده. وربما أغلق اتجاه إرساله وبقي يقرأ الاتجاه الآخر. لا تستطيع حقائق النقل وحدها الفصل بين هذه الحالات.

RFC 9846 هو معيار IETF مقترح لـ TLS 1.3 صدر في يوليو 2026. يحل محل RFC 8446 مع إبقاء نسخة البروتوكول نفسها وإدخال توضيحات وتحديثات متوافقة. ويعطي close_notify وظيفة دقيقة: إعلان الإغلاق المنتظم لاتجاه واحد من الاتصال. يقول المرسل إنه لن يرسل رسائل TLS أخرى على ذلك الاتصال. وبعد استلام التنبيه يجب تجاهل أي بيانات لاحقة، وعلى تنفيذ TLS أن يبلغ التطبيق بنهاية البيانات.

تكمن الدلالة التشغيلية في عبارة «اتجاه واحد». يستطيع أي طرف إرسال close_notify لإغلاق جانب الكتابة لديه من دون أن يؤثر ذلك في جانب القراءة. يمكن للعميل أن ينهي الإرسال ويواصل انتظار الرد، ويمكن للخادم أن ينهي الإرسال مع مواصلة استقبال ما بقي. لا يحول التنبيه الواحد الاتصال إلى إغلاق متناظر، ولا يحول تنبيهان اتجاهيان إلى تصويت على تثبيت موزع.

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

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

يسجل سجل معلمات TLS لدى IANA رمز وصف close_notify. كما يعيد RFC 9846 اشتراط إرساله بمستوى warning القديم. لا تعني كلمة «تحذير» أن الإرسال اختياري، ولا تمثل نجاحاً أو فشلاً تجارياً. إلزام الإرسال وشدة التنبيه ونتيجة التطبيق أسئلة منفصلة. أما تنبيهات الخطأ فتغلق الاتصال إغلاقاً إجهاضياً وتمنع البيانات اللاحقة، ولذلك لا تساوي الإغلاق المنتظم.

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

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

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

يوفر RFC 9293 نموذج TCP الواقع تحت كثير من اتصالات TLS، بما فيه الإغلاق المستقل لجانب الإرسال. ويحدد RFC 9110 دلالات HTTP، فيما يحدد RFC 9112 تأطير رسائل HTTP/1.1. يمكن تركيب هذه الطبقات، لكن التركيب لا يمحو شروط الاكتمال الخاصة بكل واحدة منها.

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

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

لا ينقذ user_canceled هذا التفسير. يستخدمه RFC 9846 للدلالة على إلغاء المصافحة لأسباب لا تتعلق بفشل البروتوكول، ويجب أن يتبعه close_notify، وينبغي ألا يجعل المتلقي يتوقف عن القراءة قبل الإغلاق. تصف هذه الإشارات حالة TLS، ولا ترمز إلى رد دفعة أو إلغاء طلب أو سحب موافقة في التطبيق.

يترك المعيار سلطة دورة حياة الاتصال لملف الاستخدام. فإذا سمح بروتوكول ببيانات غير TLS على النقل الأساسي نفسه بعد إغلاق TLS، وجب على تنفيذ TLS أن يستقبل close_notify قبل أن يبلغ التطبيق بانتهاء بيانات TLS. وعلى نحو أوسع، يصرح RFC 9846 بأنه لا يملي كيف يدير ملف الاستخدام النقل أو متى يفتح الاتصالات ويغلقها.

يمنع هذا الحد تعميماً غير صحيح. يستخدم RFC 9001 TLS لحماية مصافحة QUIC، لكنه يستبدل حماية سجلات TLS ويعتمد آليات QUIC الخاصة لإغلاق الاتصال. ويمنح RFC 9147 DTLS 1.3 سياقه الخاص بالرزم. لا يجوز نقل حكم صمم لدفق TLS مرتب إلى كل نقل مشفر لمجرد اشتراكها في بعض الأدوات التشفيرية.

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

تظهر ثلاثة توقيتات متجاورة كثيراً في التحقيقات: آخر كتابة للتطبيق، وآخر سجل TLS مقبول، وتنبيه الإغلاق. تساعد المجاورة في ترتيب الوقائع، لكنها لا تصبح إيصالاً سببياً. يستطيع الخادم الإغلاق بعد وضع العمل في طابور وقبل تثبيته، أو بعد أن يقرر عدم تنفيذه. وحده منطق حالة التطبيق يملك النتيجة المعتمدة.

يقدم RFC 5116 واجهة مشتركة للتشفير الموثق. يحدد حماية النص المشفر والبيانات المصاحبة، لكنه لا يجعل سلامة التشفير دليلاً على قصد تجاري. إثبات أن التنبيه جاء داخل القناة الحالية يختلف عن إثبات أن نظاماً بعيداً أحدث تغييراً دائماً.

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

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

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

كذلك لا ينبغي للإغلاق النظيف أن يمحو عدم اليقين. الحالة «غير معروفة» ليست فشلاً في التصميم إذا كانت الأدلة ناقصة؛ بل هي وصف صادق يمنع النظام من اتخاذ قرار غير قابل للعكس. يمكن بعد ذلك إجراء مطابقة بمعرّف العملية أو استعلام عن الحالة أو إعادة محاولة آمنة. أما تحويل الإغلاق إلى نجاح فيخفي الحاجة إلى هذه الآليات.

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

المصادر