ယခု Part 4 ကို မဖတ်ခင် Part 1, 2, 3 ကို အရင်ဖတ်ပေးဖို့ အကြံပြုပါတယ်ခင်ဗျ။
https://ouo.io/ouheba (Part 1)
https://ouo.io/H09gObh (Part 2)
https://ouo.io/m6gNl3 (Part 3)
Digital certificates တွေအကြောင်းကို သိဖို့လိုလာပါတယ်။ အရင် အပိုင်းက ပြဿနာကို ကြည့်မယ်ဆိုရင် Server မဟုတ်တဲ့ အခြား entity တစ်ခုက သူ့ရဲ့ public key ကိုသုံး server ယောင်ဆောင်ပြီး client (ကျနော်တို့/လက်ခံသူ) ဆီကို ပေးပို့လာနိုင်ပါတယ်။ အဲ့အခါမှာ client အနေနဲ့ သူ့ဆီရောက်လာတာ server ဆီက public key ပဲလား တခြားဆီကလားဆိုတာ ခွဲခြားလို့မရပါဘူး။
အဲ့တော့ မှားပြီး ကြားထဲက (attacker ဆီက) အယောင်ဆောင်ပြီးလာတဲ့ public key နဲ့သာ session key ကို encrypt လုပ်ပြီး client က ပြန်ပို့လိုက်ရင် ကြားထဲက ဆရာကလည်း အဲ့ဒီ encrypt လုပ်ထားတဲ့ message လေးကို ယူပြီး သူ့မှာရှိတဲ့ corresponding private key နဲ့ decrypt လုပ်ပြီး session key ကို အလွယ်တကူရသွားနိုင်ပါတယ်။ အဲ့တာဆို နောက်ပိုင်း client က session key နဲ့ encrypt လုပ်ပြီး ပို့သမျှကို ကြားကဆရာက ထိုင်ဖတ်နေနိုင်မှာပဲဖြစ်ပါတယ်။ သူ့မှာလည်း အလားတူ session key ရှိနေပြီကိုး။
ဒီလို ပြသနာတွေကို ဖြေရှင်းနိုင်ဖို့ digital certificate နဲ့ certificate authority ဆိုတာ ပေါ်ပေါက်လာပါတယ်။
Certificate authority တွေဆိုတာကတော့ digital certificate တွေကို issue လုပ်ပေးတဲ့ ကြားခံ (third party) ယုံကြည်ရတဲ့ အဖွဲ့အစည်းတွေပဲ ဖြစ်ပါတယ်။
ဒီအခါမှာတော့ client နဲ့ server နဲ့ဆက်သွယ်မှုတွေမလုပ်ခင်မှာ server က certificate authority နဲ့ အရင် ချိတ်ဆက်ထားရပါတယ်။ ကားလိုင်စင်ဝင်ထားသလိုပါပဲ။ အရင်ဆုံး server ရဲ့ public key ကို certificate authority ထံပေးပို့ရပါတယ်။ ပေးပို့လာတဲ့ public key ကို certificate authority ကသူ့ရဲ့ private key ကိုသုံးပြီး encrypt လုပ်လိုက်ပါတယ်။ လုပ်ထားတဲ့ encrypted message ကို digital certificate လို့ခေါ်တာပါ။ ပြီးတော့မှ certificate authority က server’s original public key + digital certificate ကိုတွဲပြီး server ဆီကို ပြန်ပို့ပေးပါတယ်။
ဒါဆိုရင် client ကဆက်သွယ်လာတဲ့ အခါမှာ server က အရင်လို public key တစ်ခုတည်းကိုပဲ တန်းမပို့တော့ပါဘူး။ သူရဲ့ public key + digital certificate ကိုအမြဲတွဲတွဲပို့ပါတယ်။ client အနေနဲ့ ထိုအတွဲ ကို လက်ခံရရှိတဲ့အခါမှာ အရင်ဆုံး digital certificate ကိုကြည့်ပါတယ်။ ဘယ် certificate authority က လက်မှတ်ထိုးပေးထားသလဲ ဆိုတာပေါ့။
ကျနော်တို့ရဲ့ browser ထဲမှာ verify ဖြစ်ထားတဲ့ certificate authority တွေရဲ့ public key တွေရှိပါတယ်။ ကျနော်တို့ install လုပ်ကတည်းက internet ချိတ်က်ရမယ့် device တွေဝယ်ကတည်းက ပါပြီးသားဖြစ်ပါတယ်။ (ဥပမာ google ကပေးတဲ့ certificate လိုမျိုးပါ၊ root certificate ပေးနိုင်တဲ့ authority ကရာဂဏန်းပဲရှိပါတယ်) root certificate နဲ့ ရိုးရိုး certificate နဲ့ ကွာခြားချက်ကို ဆက်ပြောပါ့မယ်။
အဲ့တာကိုကြည့်ပြီး client က အရင်ဆုံး server ရဲ့ public key မှာပါလာတဲ့ digital certificate ကို သက်ဆိုင်ရာ certificate authority ရဲ့ public key ကို သုံးပြီး decrypt လုပ်ပါတယ်။ (digital certificate တွေဟာ encrypt လုပ်ထားတဲ့ message တွေလိုပဲဆိုတာ အပေါ်မှာ ပြောခဲ့ပြီးသားဖြစ်ပါတယ်)
အဲ့လို decrypt လုပ်လို့မှန်တယ်ဆိုရင် server ကပို့လိုက်တဲ့ public key နဲ့ တစ်ထေရာတည်း တူတဲ့ public key ကို ဖော်ထုတ်ရရှိမှာပဲဖြစ်ပါတယ်။ အဲ့လို တစ်ထေရာတည်း တူရင် ဒီ certificate authority အတွက်တော့ ဒီ key က verify ဖြစ်တယ်လို့ပြောလို့ရပါပြီ။
ဒါပေမဲ့ မပြီးသေးပါဘူး။ server ကို issue လုပ်ပေးထားတဲ့ certificate authority က root authority ဟုတ်ချင်မှ ဟုတ်ပါမယ်။ root certificate authority တွေကသာ အစစ်အမှန် verify ဖြစ်တာပါ။ အဲ့တာဆို သူ့ကို (server ကို) verify လုပ်ပေးထားတဲ့ certificate authority ကိုလည်း ပြန်ပြီး verify လုပ်ပေးဖို့ လိုလာပြန်ပါပြီ။
ထူးခြားပြီး ကျနော် အပေါ်မှာ mention မလုပ်ခဲ့တာတစ်ခုက ပထမ certificate authority (server ရဲ့ certificate authority) ရဲ့ public key မှာလည်း digital certificate တစ်ခုတွဲပြီး ပါရှိနေပါတယ်။ အဲ့ဒီ digital certificate ကိုလည်း certificate authority နောက်တစ်ခုခုက sign လုပ်ပေးထားတာပါ။
အဲ့တာဆို browser (client) က လည်း ထုံးစံအတိုင်း အဲ့ digital certificate ကိုယူပြီး သူ့အထက်က သူ့ကို sign လုပ်ထားပေးတဲ့ certificate authority ရဲ့ public key နဲ့ decrypt လုပ်ပါတယ်။ လုပ်ရင် public key တစ်ခုထွက်လာမှာဖြစ်ပြီး အဲ့ဒီ key နဲ့ မူလ certificate authority ရဲ့ public key နဲ့ တူနေရင် မူလ certificate authority ဟာလည်း verify ဖြစ်တယ်လို့ သတ်မှတ်လို့ရပါပြီ။
အဲ့လိုပဲ ခုစစ်ဆေးလိုက်တဲ့ (မူလ certificate authority ရဲ့ အထက်မှာရှိတဲ့) certificate authority ကိုလည်း သူ့အထက်က certificate authority နဲ့ အပေါ်က နည်းအတိုင်းပဲ verify ထပ်လုပ်ပါတယ်။ ဒီလိုအဆင့်ဆင့် verify လုပ်ပြီး နောက်ဆုံး အဆုံးသတ်ရမယ့်နေရာကတော့ root certificate authority တွေပါ။ သူတို့တွေကို browser မှာ ထည့်သွင်းပေးပြီးသားမလို့ certificate တစ်ခုကို root authority က sign လုပ်ထားရင် ထပ်မစစ်တော့ပါဘူး။
ဒီလိုမျိုး နောက်ဆုံး root certificate အထိ အဆင့်ဆင့် verify လုပ်တာကို chain of trust လို့ခေါ်ပါတယ်။ chain of trust ကတစ်နေရာမှာ ပြတ်နေရင် သို့မဟုတ် server က ဘယ် certificate authority နဲ့မှ verify မလုပ်ရသေးရင် website တွေမှာ warning အနီနဲ့ Not Secure ဆိုပြီးပေါ်နေတာကို တွေ့နိုင်မှာပါ။ မြင်လည်းမြင်ဖူးကြမယ်လို့ ယူဆပါတယ်။
root certificate အထိ verify ဖြစ်တယ်ဆိုရင်တော့ secure ဆိုပြီး Lock 🔒 ပုံလေး ဘယ်ဘက်အပေါ်မှာ ပေါ်နေမှာပဲ ဖြစ်ပါတယ်။ သတိထားမိတဲ့ သူများလည်းရှိမှာပါ။
attacker တွေ တုပလိုသူတွေ အနေနဲ့ certificate authority ရဲ့ private key မရှိတဲ့ အတွက် ဒီ chain of trust ကို ဖြတ်ဖို့ အင်မတန်ခက်ခဲပါတယ်။ သိုပေမဲ့ certificate authority နဲ့ပတ်သတ်ပြီး private key leaked ဖြစ်သွားတဲ့ ဖြစ်စဉ်တစ်ခုတော့ ရှိခဲ့ဖူးပါတယ်။ ဒီအကြောင်းကိုတော့ မိမိဘာသာ ရှာဖတ်နိုင်ပါတယ်။ သို့သော်လည်း လက်တလောမှာတော့ ကျနော်တို့ ပေးပို့ ရယူနေတဲ့ အင်တာနက်ပေါ်က ဆက်သွယ်မှုတွေအားလုံး ဒီနည်းနဲ့ လုံခြုံနေဆဲပဲ ဖြစ်ပါတယ်။
အဲ့တာဆို နောက်တစ်ခါ facebook ပဲသုံးသုံး google ပဲရှာရှာ ကိုယ့်ရှေ့ကို စာမျက်နှာတစ်ခု ရုပ်တစ်ခု အသံတစ်သံ ထွက်လာဖို့ နောက်ကွယ်က secure ဖြစ်အောင် လုပ်ပေးရတဲ့ process တွေကို အကြမ်းဖျင်း နားလည်နိုင်ပြီလို့ ယူဆပါတယ်ခင်ဗျ။
Kevin
Next Post, Previous Post မနှိပ်ဘဲ OUO Link ကနေ ၁ပုဒ်ချင်းဝင်ဖတ်ပြီး ကူညီပါ။
အသိအမြင်၊ အတွေးအခေါ် အသစ်တစ်ခုခုရသွားလို့ လှူဒါန်းလိုပါက Science Nuts (Facebook Page) ကို ဆက်သွယ်လှူဒါန်းနိုင်ပါတယ်။
လှူသမျှငွေအကုန်လုံးကို လိုအပ်တဲ့နေရာတွေမှာ ပြန်လည်လှူဒါန်းပေးသွားမှာပါ။
Science Nuts 