પર્લે SOCKS કનેક્શન ખોલ્યા પછી TLS ઉમેરો

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 રૂપરેખાંકન વાપરો.

SOCKS પગલું નિષ્ફળ જાય તો TLS પરિમાણો બદલવાથી તે સુધરશે નહીં. SOCKS સફળ થાય અને TLS નિષ્ફળ જાય તો પ્રમાણપત્ર અને હોસ્ટનામની ભૂલ પુરાવા તરીકે રાખો, સામાન્ય પ્રોક્સી ખામી તરીકે ગણશો નહીં.

મોડ્યુલનાં નામ પણ મહત્વનાં છે: IO::Socket::Socks અને IO::Socket::SSL જુદા જુદા કન્સ્ટ્રક્ટર અને અપગ્રેડ વર્તન આપે છે. ફક્ત પ્રોક્સી સુધી પહોંચેલું કાચું TCP સોકેટ હજી SOCKS લક્ષ્ય-વાટાઘાટ પૂર્ણ કર્યું નથી.