प्रॉक्सी के साथ WRONG_VERSION_NUMBER: HTTP बनाम HTTPS जाँचें

त्रुटि कहती है “गलत संस्करण”, इसलिए TLS संस्करण बदलना शुरू करने का लोभ होता है। प्रॉक्सी के साथ, पहले की एक संभावना जाँचें: क्या क्लाइंट ने TLS हैंडशेक उस पोर्ट पर भेजा जो सादे HTTP की प्रतीक्षा कर रहा था?

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 अस्वीकार को नहीं समझा सकता।