Lidhja SOCKS dhe lidhja TLS kanë detyra të ndryshme. Së pari merrni një rrjedhë bajtesh drejt destinacionit përmes SOCKS. Pastaj nisni TLS mbi atë rrjedhë, duke identifikuar faqen e destinacionit dhe jo proxy-n.

Për një pikë fundore TLS të stilit HTTPS, rregullimi mund të jetë:

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

Për një objektiv publik HTTPS në një rrugë proxy publike të lejuar, lista e proxy-ve SOCKS5 ofron kandidatë për ProxyAddr dhe ProxyPort. Fragmenti ndërton shtresat e transportit; aplikacioni duhet ende të dërgojë protokollin që pret destinacioni dhe ta mbyllë socket-in kur të mbarojë.

Ruani emrin e synuar të palës

Pika fundore e proxy-t i përket lidhjes së parë. SNI i TLS dhe verifikimi i emrit të hostit kanë të bëjnë me example.com. Përdorimi i emrit të hostit të proxy-t në atë fazë mund të kërkojë ose verifikojë një identitet të gabuar.

Konfigurimi i depozitës së besimit është një kërkesë tjetër e pavarur. Përdorni konfigurimin e CA-së të synuar nga aplikacioni në vend të një callback që beson gjithçka, të kopjuar nga një shembull diagnostikues.

Nëse hapi SOCKS dështon, ndryshimi i parametrave të TLS nuk do ta rregullojë. Nëse SOCKS ka sukses dhe TLS dështon, ruani gabimin e certifikatës dhe të emrit të hostit si provë në vend që ta trajtoni si një ndërprerje të përgjithshme të proxy-t.

Edhe emrat e moduleve kanë rëndësi: IO::Socket::Socks dhe IO::Socket::SSL ofrojnë konstruktorë dhe sjellje përditësimi të ndryshme. Një socket TCP i papërpunuar që arriti vetëm te proxy nuk e ka përfunduar ende negocimin e destinacionit SOCKS.

Artikuj të ngjashëm