ایک اضافی نئی لائن CONNECT کے بعد TLS کو توڑ سکتی ہے

جب CONNECT 200 واپس کرے اور TLS فوراً ڈیکوڈ نہ کر سکے، تو سرٹیفکیٹ یا سائفر بدلنے سے پہلے کنیکٹر میں حد بائٹس جانچیں۔

بنایا گیا اجازت نامہ قدر پہلے ہی نئی لائن پر ختم ہو سکتا ہے۔ ایک اور سطر کا اختتام شامل کرنے سے HTTP ہیڈر جلدی ختم ہو سکتے ہیں، جس سے مطلوبہ Host فیلڈ یا دیگر سادہ متن درخواست کے پیچھے رہ جاتا ہے۔

کم سے کم HTTP/1.1 CONNECT درخواست لائنوں کے درمیان CRLF اور آخر میں خالی سطر استعمال کرتی ہے:

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

کوئی بھی اجازت نامہ فیلڈ اُس آخری خالی سطر سے پہلے رکھیں، اندر کوئی سطر وقفہ کے بغیر۔ Python میں "\n" نئی لائن ظاہر کرتا ہے؛ بیک سلیش اور حرف n والی خام اسٹرنگ نہیں۔ ہٹانے کی کوشش سے پہلے دیکھیں کہ انکوڈنگ مددگار کون سی بائٹس بناتا ہے—پرانی مددگار سطر وقفے شامل کر سکتے تھے۔

CONNECT کامیاب ہونے کے بعد، وہ باقی بائٹس سرنگ پروٹوکول کے ہیں۔ بھٹکا ہوا سادہ متن TLS کی توقع کرنے والے ساتھی تک پہنچ سکتا ہے۔ کامیاب حیثیت خراب بنی درخواست کے بعد پہلے سے قطار میں رکھی بائٹس درست نہیں کر سکتی۔

وصولی کی حد بھی جانچیں۔ ساکٹ TLS کے حوالے کرنے سے پہلے مکمل پروکسی جواب پڑھیں، جزوی پڑھائی سنبھالیں اور ہیڈرز سے آگے پڑھی گئی ہر چیز محفوظ رکھیں۔ ایک ساکٹ پڑھائی میں ایک پورا پیغام ہونا ضروری نہیں۔

اگر یہ پارسر آپ کا ہے، تو ترمیم شدہ بائٹ نمائندگی کا تار کی گرامر سے موازنہ کریں؛ پاس ورڈ چھپاتے ہوئے لمبائیاں اور سطر کی حدیں نظر آتی رکھیں۔ ایسی ایپلیکیشن کے لیے جسے صرف پروکسی کنکشن درکار ہو، برقرار رکھا گیا کنیکٹر اِس فریمنگ کوڈ کی ملکیت کی ضرورت سے بچاتا ہے۔