D'SOCKS-Verbindung an d'TLS-Verbindung hunn ënnerschiddlech Aufgaben. Kritt d'éischt e Bytestroum zum Zil duerch SOCKS. Start dann TLS iwwer dësen Troum a bestëmmt d'Zilwebsäit an net de Proxy.

Fir en TLS-Endpunkt am HTTPS-Stil kann den Opbau sou ausgesinn:

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

Fir en ëffentlecht HTTPS-Zil op enger erlaabter ëffentlecher Proxy-Route bitt déi SOCKS5-Proxy-Lëscht Kandidaten fir ProxyAddr a ProxyPort. D'Frament baut d'Transportschichten op; d'Applikatioun muss nach ëmmer de Protokoll schécken, deen d'Zil erwaart, an de Socket um Enn zoumaachen.

Behält den intendéierten Peer-Numm

Den Endpunkt vum Proxy gehéiert zur éischter Verbindung. TLS SNI an d'Hostnummverifikatioun betreffen example.com. De Proxy-Hostnumm an deem Schrëtt ze benotzen kann eng falsch Identitéit ufroen oder verifiéieren.

D'Konfiguratioun vum Vertrauensspäicher ass eng aner onofhängeg Ufuerderung. Benotzt déi intendéiert CA-Konfiguratioun vun der Applikatioun amplaz vun engem Callback, deen allem vertraut, kopéiert aus engem Diagnosebeispill.

Wann de SOCKS-Schrëtt feelt, hëlleft et net, TLS-Parameter ze änneren. Wann SOCKS geléngt an TLS feelt, behält de Certificat- an Hostnummfehler als Beweis, amplaz en als allgemenge Proxy-Ausfall ze behandelen.

D'Modulnumme spille och eng Roll: IO::Socket::Socks an IO::Socket::SSL bidden ënnerschiddlech Konstruktoren an Upgrade-Verhalen. En rauen TCP-Socket, deen nëmmen de Proxy erreecht huet, huet d'SOCKS-Zilverhandlung nach net fäerdeg.

Ähnlech Artikelen