SOCKS կապը և TLS կապը տարբեր աշխատանքներ ունեն։ Նախ SOCKS-ի միջոցով ստացեք բայթային հոսք դեպի նպատակակետը։ Այնուհետև այդ հոսքի վրա սկսեք TLS՝ նույնականացնելով նպատակակետ կայքը, ոչ թե վստահված սերվերը։

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();

Թույլատրված հանրային վստահված սերվերի երթուղու վրա գտնվող հանրային HTTPS նպատակակետի համար SOCKS5 վստահված սերվերների ցանկը առաջարկում է թեկնածուներ ProxyAddr-ի և ProxyPort-ի համար։ Այս հատվածը կառուցում է տրանսպորտային շերտերը. հավելվածը դեռ պետք է ուղարկի այն արձանագրությունը, որը սպասում է նպատակակետը, և ավարտելուց հետո փակի սոքեթը։

Պահպանեք նախատեսված զուգընկերոջ անունը

Վստահված սերվերի վերջնակետը պատկանում է առաջին կապին։ TLS SNI-ն և հոսթի անվան ստուգումը վերաբերում են example.com-ին։ Այդ փուլում վստահված սերվերի հոսթի անունն օգտագործելը կարող է պահանջել կամ ստուգել սխալ ինքնություն։

Վստահության պահոցի կարգավորումը ևս մեկ անկախ պահանջ է։ Օգտագործեք հավելվածի նախատեսված CA կարգավորումը՝ ախտորոշիչ օրինակից պատճենված ամեն ինչի վստահող callback-ի փոխարեն։

Եթե SOCKS քայլը ձախողվի, TLS պարամետրերի փոփոխությունը դա չի շտկի։ Եթե SOCKS-ը հաջողվի, իսկ TLS-ը ձախողվի, պահեք վկայագրի և հոսթի անվան սխալը որպես ապացույց՝ այն ընդհանուր վստահված սերվերի խափանում չհամարելով։

Մոդուլների անունները նույնպես կարևոր են. IO::Socket::Socks-ը և IO::Socket::SSL-ը տարբեր կոնստրուկտորներ և թարմացման վարք են առաջարկում։ Միայն վստահված սերվերին հասած հում TCP սոքեթը դեռ չի ավարտել SOCKS նպատակակետի բանակցությունը։

Առնչվող հոդվածներ