WRONG_VERSION_NUMBER ከፕሮክሲ ጋር፦ HTTP እና HTTPS መሆናቸውን ያረጋግጡ

አሳሳች የSSL ስህተት ምክንያት የTLS ስሪቶችን ከመቀነስ ወይም የምስክር ወረቀት ቅንብሮችን ከመቀየር በፊት የፕሮክሲ መጓጓዣ አለመጣጣምን ይመርምሩ።

ስህተቱ “ስህተት የሆነ ስሪት” ስለሚል የ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 አለመቀበልን ማብራራት አይችልም።

ተዛማጅ ጽሑፎች