প্রক্সিসহ WRONG_VERSION_NUMBER: HTTP ও HTTPS যাচাই করুন

ত্রুটিটি “ভুল সংস্করণ” বলে, তাই TLS সংস্করণ বদলাতে শুরু করার প্রলোভন জাগে। প্রক্সির ক্ষেত্রে এর আগের একটি সম্ভাবনা দেখুন: ক্লায়েন্ট কি সাধারণ HTTP-র জন্য অপেক্ষারত পোর্টে TLS হ্যান্ডশেক পাঠিয়েছিল?

https://example.com/-এর মতো গন্তব্য আর http://proxy.example:8080-এর মতো প্রক্সি একটি সাধারণ জোড়। দ্বিতীয় URL-টি HTTPS-এ বদলালে ক্লায়েন্টকে বলা হয় সে প্রক্সির সঙ্গেই নিজের কথাবার্তা এনক্রিপ্ট করবে। এটি HTTPS সাইট অনুমোদনের নির্দেশ নয়।

প্রথম TLS কথোপকথনটি খুঁজুন

HTTP প্রক্সির ক্ষেত্রে ক্লায়েন্ট প্রথমে CONNECT পাঠিয়ে HTTP উত্তর পেতে পারে। তারপরেই টানেলের ভিতরে গন্তব্যের TLS শুরু করে। HTTPS প্রক্সির ক্ষেত্রে আগে আসে প্রক্সির সঙ্গে আলাদা TLS সংযোগ।

HTTP ত্রুটি পাতা বা অন্য সাধারণ লেখা পাওয়া TLS পার্সার প্রোটোকল ত্রুটি জানাতে পারে। ওই ভাষা সাইটটি কোন TLS সংস্করণ সমর্থন করে, এমনকি সাইটের সঙ্গে যোগাযোগ হয়েছিল কি না, তাও প্রমাণ করে না।

1. প্রক্সির URL, তার স্কিমসহ, এবং এন্ডপয়েন্টের নথিভুক্ত প্রোটোকল লিখে রাখুন।
2. ব্যর্থতা CONNECT উত্তরের আগে, গন্তব্য TLS-এর সময়, না প্রক্সির নিজের সার্টিফিকেট যাচাইয়ের সময় ঘটেছে তা নির্ধারণ করুন।
3. পুরোনো কোনো অস্থায়ী সমাধান তুলনা করার সময় প্রকৃত ক্লায়েন্ট ও নির্ভরতার সংস্করণ দেখুন। আগের প্রক্সি বাস্তবায়ন কখনো স্কিমকে ভিন্নভাবে ধরত।

কয়েকটি সংশোধন ভিন্ন ভিন্ন কারণে ভুল হতে পারে। HTTP প্রক্সি তালিকা এই ধরনের পথে অনুমোদিত সরকারি অনুরোধের জন্য সাধারণ HTTP এন্ডপয়েন্টের প্রার্থী দেয়। সাধারণ HTTP এন্ডপয়েন্টের জন্য HTTP প্রক্সি স্কিম দরকার; সত্যিই TLS-সক্রিয় এন্ডপয়েন্ট HTTPS ও তার সার্টিফিকেট যাচাই ধরে রাখা উচিত। CONNECT প্রত্যাখ্যানকারী প্রক্সির জন্য সমর্থিত সেবা বা নীতি দরকার, লাইব্রেরির ইচ্ছেমতো ডাউনগ্রেড নয়।

প্রথম লক্ষণীয় ব্যর্থতাটি ধরে রাখুন। সার্টিফিকেট যাচাই বন্ধ করলে কেবল HTTP শোনা কোনও সেবা TLS বলতে শিখবে না, আর পুরোনো সাইফার নীতি বেছে নেওয়া সাইটের হ্যান্ডশেকের আগে পাঠানো HTTP প্রত্যাখ্যান ব্যাখ্যা করতে পারে না।