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 ငြင်းပယ်မှုကို ရှင်းပြနိုင်မည် မဟုတ်ပါ။

ဆက်စပ်ဆောင်းပါးများ