الخلاصة

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

سلامة ما وصل لا تثبت غياب ما لم يصل

لنتصور أن المستقبل يتحقق بنجاح من كل سجل TLS، ثم يرى EOF. النتيجة الأولى صحيحة: البادئة التي وصلت محمية ولم تتغير. لكن النتيجة الثانية لا تتبع منها: ربما كانت هناك سجلات لاحقة اختفت قبل أن تعبر الشبكة.

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

واجه TLS 1.0 هذا الخطر بإدخال تنبيه close_notify. يرسل الطرف تصريحاً ضمن تسلسل السجلات المحمي بأنه لن يرسل رسائل أخرى على الاتصال. وأي سجل يأتي بعد التنبيه ينبغي تجاهله.

لم يحول ذلك TLS إلى صيغة للوثائق. فالتنبيه يحدد الحد الذي تستطيع طبقة السجلات إثباته: لا مزيد من رسائل TLS من هذا المرسل. أما اكتمال رد HTTP أو ملف أو معاملة فيحتاج إلى دليل من الطبقة التي تفهم بنيته.

كان للإغلاق الناقص ثمن في TLS الأول

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

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

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

التناظر الإجباري كان يستطيع بتر الاتجاه العكسي

قبل TLS 1.3، كان استلام close_notify يوجب إرسال التنبيه المقابل فوراً، وإغلاق الاتصال، والتخلص من الكتابات المعلقة. افترضت القاعدة أن الاتجاهين ينتهيان معاً.

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

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

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

يمنح HTTP الرسالة حدوداً لا يراها TLS

فصلت مواصفة HTTP عبر TLS بين سلامة البيانات المستلمة واكتمالها. الإغلاق المبكر لا يجعل البادئة الموثقة غير آمنة، لكنه قد يعني أن بيانات لاحقة بُترت. ولأن TLS لا يعرف حدود طلبات HTTP وردوده، فعلى العميل فحص التأطير الخاص بـHTTP.

تحافظ مواصفة HTTP/1.1 الحديثة على هذا التقسيم. يثبت Content-Length الاكتمال حين يصل العدد المحدد تماماً، وللترميز المجزأ قطعة نهائية بحجم صفر. إذا غاب الحد، فالرسالة ناقصة. أما الرد الذي يحده إغلاق الاتصال فلا يكتمل فوق TLS إلا بإغلاق صالح؛ وإلا فقد يؤدي قبول البادئة إلى هجوم بتر.

يوضح HTTP/2 الفرق على مستوى التدفقات. يغلق END_STREAM في RFC 9113 اتجاه تدفق HTTP واحد، بينما تستمر تدفقات أخرى على الاتصال نفسه. لذلك يمكن أن تثبت نهاية التدفق قبل أن تنتهي قناة TLS المشتركة لاحقاً.

ادعاء واحد لا شهادة شاملة

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

EOF واقعة في النقل. والتنبيه دليل محمي على نية الإرسال. أما الطول أو نهاية القطع أو END_STREAM فهي أدلة على بنية التطبيق. تفصل الأنظمة الموثوقة بين هذه الحقائق، ولا تجمعها في حالة مبهمة اسمها «نجاح».

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

يعتمد هذا المقال على RFC 2246 وRFC 2818 وRFC 5246 وRFC 8446 وRFC 9112 وRFC 9113. توثق هذه النصوص القواعد وتطورها، لكنها لا تقيس الإعدادات الافتراضية للمكتبات الحالية أو انتشارها، ولا تحدد سبب غياب تنبيه في حادثة بعينها.