प्रोक्सीसँग WRONG_VERSION_NUMBER: HTTP र HTTPS जाँच्नुहोस्

भ्रामक SSL त्रुटिका कारण TLS संस्करण घटाउनु वा प्रमाणपत्रका सेटिङ बदल्नुअघि प्रोक्सी यातायातको असमझदारी पहिचान गर्नुहोस्।

त्रुटिले “गलत संस्करण” भन्छ, त्यसैले 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 अस्वीकार व्याख्या गर्न सकिँदैन।

सम्बन्धित लेखहरू