SOCKS ချိတ်ဆက်မှုနှင့် TLS ချိတ်ဆက်မှုတို့တွင် မတူညီသော တာဝန်များ ရှိသည်။ ပထမဦးစွာ SOCKS မှတစ်ဆင့် ဦးတည်ရာသို့ byte stream ရယူပါ။ ထို့နောက် ထို stream အပေါ်တွင် TLS စတင်ပြီး proxy မဟုတ်ဘဲ ဦးတည်ရာ ဝဘ်ဆိုက်ကို ဖော်ထုတ်ပါ။

HTTPS ပုံစံ TLS အဆုံးအမှတ်အတွက် အစီအစဉ်မှာ ဤသို့ဖြစ်နိုင်သည်။

use IO::Socket::Socks;
use IO::Socket::SSL;

my $target = 'example.com';
my $socket = IO::Socket::Socks->new(
    SocksVersion => 5,
    ProxyAddr => '127.0.0.1',
    ProxyPort => 1080,
    ConnectAddr => $target,
    ConnectPort => 443,
) or die $!;

IO::Socket::SSL->start_SSL(
    $socket,
    SSL_hostname => $target,
    SSL_verifycn_name => $target,
    SSL_verifycn_scheme => 'http',
    SSL_verify_mode => SSL_VERIFY_PEER,
) or die IO::Socket::SSL::errstr();

ခွင့်ပြုထားသော အများသူငှာ proxy လမ်းကြောင်းရှိ အများသူငှာ HTTPS ပစ်မှတ်အတွက် SOCKS5 proxy စာရင်း သည် ProxyAddr နှင့် ProxyPort အတွက် ကိုယ်စားလှယ်လောင်းများ ပေးသည်။ ဤအပိုင်းသည် သယ်ယူပို့ဆောင်ရေး အလွှာများကို တည်ဆောက်သည်။ အပလီကေးရှင်းသည် ဦးတည်ရာ မျှော်လင့်သော ပရိုတိုကောကို ပို့ရပြီး ပြီးဆုံးသောအခါ socket ကို ပိတ်ရမည်။

ရည်ရွယ်ထားသော peer အမည်ကို ထိန်းသိမ်းပါ

Proxy အဆုံးအမှတ်သည် ပထမ ချိတ်ဆက်မှုနှင့် သက်ဆိုင်သည်။ TLS SNI နှင့် host အမည် စစ်ဆေးခြင်းသည် example.com နှင့် သက်ဆိုင်သည်။ ထိုအဆင့်တွင် proxy ၏ host အမည်ကို အသုံးပြုခြင်းသည် မှားယွင်းသော အထောက်အထားကို တောင်းဆိုနိုင် သို့မဟုတ် စစ်ဆေးနိုင်သည်။

ယုံကြည်မှု သိုလှောင်ရာ ဖွဲ့စည်းမှုသည် နောက်ထပ် သီးခြား လိုအပ်ချက် ဖြစ်သည်။ ရောဂါရှာဖွေရေး နမူနာမှ ကူးယူထားသော အရာအားလုံးကို ယုံကြည်သည့် callback အစား အပလီကေးရှင်း၏ ရည်ရွယ်ထားသော CA ဖွဲ့စည်းမှုကို အသုံးပြုပါ။

SOCKS အဆင့် မအောင်မြင်ပါက TLS ပါရာမီတာများ ပြောင်းလဲခြင်းက မပြုပြင်နိုင်ပါ။ SOCKS အောင်မြင်ပြီး TLS မအောင်မြင်ပါက လက်မှတ်နှင့် host အမည် အမှား ကို အထောက်အထားအဖြစ် သိမ်းထားပြီး ယေဘုယျ proxy ပျက်ယွင်းမှုအဖြစ် မသတ်မှတ်ပါနှင့်။

မော်ဂျူး အမည်များလည်း အရေးကြီးသည်။ IO::Socket::Socks နှင့် IO::Socket::SSL သည် မတူညီသော constructor နှင့် upgrade အပြုအမူကို ပေးသည်။ proxy သို့ ရောက်ရှိရုံသာ ဖြစ်သော အကြမ်း TCP socket သည် SOCKS ဦးတည်ရာ ညှိနှိုင်းမှုကို မပြီးစီးသေးပါ။

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