प्रॉक्सीसह 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 नकार स्पष्ट होऊ शकत नाही.