SOCKS မှတစ်ဆင့် Java TLS အတွက် ဦးတည်ရာ၏ အထောက်အထားကို အသုံးပြုပါ

SOCKS endpoint က သင့်ကို ဝဘ်ဆိုက်သို့ ပို့ဆောင်ပေးသည်။ ထိုချိတ်ဆက်မှုအတွင်းရှိ TLS လုပ်ဖော်ကိုင်ဖက်သည် ဝဘ်ဆိုက်ကိုယ်တိုင်ဖြစ်သောကြောင့် ဦးတည်ရာ၏ hostname ကို အလွှာတင်ထားသော socket စက်ရုံသို့ ပေးပို့ပါ။

String destination = "example.com";
int destinationPort = 443;
Proxy proxy = new Proxy(
    Proxy.Type.SOCKS,
    new InetSocketAddress("127.0.0.1", 1080)
);

try (Socket transport = new Socket(proxy)) {
    transport.connect(
        InetSocketAddress.createUnresolved(destination, destinationPort),
        5000
    );
    SSLSocketFactory factory =
        (SSLSocketFactory) SSLSocketFactory.getDefault();
    try (SSLSocket tls = (SSLSocket) factory.createSocket(
            transport, destination, destinationPort, true)) {
        SSLParameters parameters = tls.getSSLParameters();
        parameters.setEndpointIdentificationAlgorithm("HTTPS");
        tls.setSSLParameters(parameters);
        tls.setSoTimeout(15000);
        tls.startHandshake();
        // Send the application's HTTPS request through tls.
    }
}

ဤအပိုင်းသည် စံ Java ကွန်ရက်နှင့် TLS import များ၊ ရှိပြီးသား မူလ trust ဖွဲ့စည်းမှုနှင့် proxy အထောက်အထား မလိုအပ်သော SOCKS ချိတ်ဆက်မှုကို ယူဆသည်။ ၎င်းသည် handshake ကို လုပ်ဆောင်သည်၊ သို့သော် application သည် ဆာဗာ မျှော်လင့်သော ပုံစံဖြင့် HTTP တောင်းဆိုမှု ပို့ရန် လိုအပ်ဆဲဖြစ်သည်။ ခွင့်ပြုထားသော အများသူငှာ လမ်းကြောင်းများရှိ အများသူငှာ HTTPS ပစ်မှတ်များအတွက် SOCKS proxy စာရင်း သည် ကိုယ်စားလှယ်လောင်း endpoint များကို ပေးသည်။ ဆာဗာ၏ ဗားရှင်းနှင့် hostname ပံ့ပိုးမှုကို ဤ Java socket လမ်းကြောင်းနှင့် ကိုက်ညီအောင် ချိန်ညှိပါ။

နမူနာရှိ အထောက်အထား နှစ်ခုကို ဖတ်ပါ

127.0.0.1:1080 သည် proxy endpoint ဖြစ်ပြီး ဤ Java လုပ်ငန်းစဉ်မှ ရောက်ရှိနိုင်သည်။ destination နှင့် destinationPort သည် ဝဘ်ဆိုက်ကို ဖော်ပြသည်။ createUnresolved သည် client တွင် ကြိုတင် ဖြေရှင်းမည့်အစား ထို hostname ကို SOCKS လမ်းကြောင်းအတွက် ထိန်းသိမ်းထားသည်။

အလွှာတင်ထားသော createSocket သည် ဦးတည်ရာ၏ အထောက်အထားကို လက်ခံသည်။ setEndpointIdentificationAlgorithm("HTTPS") သည် ၎င်း၏ hostname စစ်ဆေးမှုများကို ရှင်းလင်းစွာ တောင်းဆိုသည်။ အကြမ်းထည် SSLSocket ၏ လက်မှတ်ကွင်းဆက် trust သည် hostname အတည်ပြုမှု ဖွင့်ထားသည်ဟု သူ့အလိုလို သက်သေမပြပါ။ မကိုက်ညီမှုကို နှိမ်နင်းရန် proxy ၏ အမည် သို့မဟုတ် loopback ကို အစားထိုးခြင်းသည် မှားယွင်းသော endpoint ကို အတည်ပြုနိုင်သည်။

trust နှင့် သန့်ရှင်းရေးကို ၎င်းတို့၏ အဆင့်များနှင့်အတူ ထားပါ

မူလ စက်ရုံသည် JVM ၏ ဖွဲ့စည်းထားသော trust အစီအစဉ်ကို အသုံးပြုသည်။ သီးသန့် လိုအပ်ချက်ရှိသော application သည် အစား ၎င်း၏ မှန်ကန်စွာ စတင်ထားသော SSLContext စက်ရုံကို အသုံးပြုနိုင်သည်။ ထို ရွေးချယ်မှုသည် SOCKS လမ်းကြောင်းနှင့် သီးခြားဖြစ်သည်။ လက်မှတ်တိုင်းကို လက်ခံသော trust မန်နေဂျာသည် မှားယွင်းသော peer အမည်ကို ပြုပြင်မပေးပါ။

SOCKS ငြင်းပယ်မှုသည် TLS မတိုင်မီ ဖြစ်ပေါ်သည်။ မယုံကြည်ရသော လက်မှတ် သို့မဟုတ် မှားယွင်းသော hostname သည် TLS အတွင်း မအောင်မြင်ပါ။ ထို့နောက် HTTP အမှား ဖြစ်နိုင်သည်။ proxy သို့ ဝင်ရောက်ခြင်းသည် tunnel တောင်းဆိုမှုကို ခွင့်ပြုသည်၊ အတွင်းရှိ ဝဘ်ဆိုက်ကို အတည်ပြုခြင်း မဟုတ်ပါ။

အလိုအလျောက် ပိတ်ခြင်း ဖွင့်ထားစဉ် အလွှာတင်ထားသော socket ကို ပိတ်ခြင်းသည် ၎င်း၏ သယ်ယူပို့ဆောင်မှုကို ပိတ်သည်။ ပုံမှန် ပြီးဆုံးမှု မတိုင်မီ ထုပ်ပိုးခြင်း သို့မဟုတ် handshake မအောင်မြင်ပါက အပြင် အရင်းအမြစ် နယ်ပယ်ကလည်း ထို သယ်ယူပို့ဆောင်မှုကို ပိတ်သည်။