سطر جديد إضافي واحد قد يكسر TLS بعد CONNECT

عندما يعيد CONNECT الرمز 200 ويفشل TLS فورًا في فك الترميز، افحص بايتات الحدود في الموصل قبل تغيير الشهادات أو الأصفار.

قد تنتهي قيمة تفويض مُولَّدة بالفعل بسطر جديد. إضافة نهاية سطر أخرى قد تُنهي رؤوس HTTP مبكرًا، تاركةً حقل Host المقصود أو نصًا صريحًا آخر خلف الطلب.

يستخدم طلب CONNECT الأدنى في HTTP/1.1 رمز CRLF بين الأسطر وسطرًا فارغًا في النهاية:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

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

بعد نجاح CONNECT، تنتمي تلك البايتات المتبقية إلى البروتوكول النفقي. قد يصل نص صريح شارد إلى طرف يتوقع TLS. لا يمكن للحالة الناجحة إصلاح بايتات اصطفت بالفعل بعد طلب مشوّه.

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

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