একটি অতিরিক্ত নতুন লাইন 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-এ হস্তান্তরের আগে সম্পূর্ণ প্রক্সি প্রতিক্রিয়া পড়ুন, আংশিক পঠন সামলান এবং হেডারের পরে পড়া সবকিছু সংরক্ষণ করুন। একটি সকেট পঠনে একটি সম্পূর্ণ বার্তা থাকতেই হবে না।

এই পার্সার আপনার হলে, সম্পাদিত বাইট উপস্থাপনা তারের ব্যাকরণের সঙ্গে তুলনা করুন; পাসওয়ার্ড লুকিয়ে দৈর্ঘ্য ও লাইন সীমানা দৃশ্যমান রাখুন। কেবল প্রক্সি সংযোগ দরকার এমন অ্যাপ্লিকেশনের জন্য, রক্ষণাবেক্ষিত সংযোগকারী এই ফ্রেমিং কোডের মালিকানা এড়ায়।