پروکسی کے ساتھ 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 مسترد ہونے کی وضاحت نہیں کر سکتا۔