SOCKS spojenie a TLS spojenie majú rôzne úlohy. Najprv získajte bajtový prúd k cieľu cez SOCKS. Potom spustite TLS nad týmto prúdom a identifikujte cieľovú webovú lokalitu, nie proxy.

Pre koncový bod TLS typu HTTPS môže usporiadanie vyzerať takto:

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

Pre verejný cieľ HTTPS na povolenej trase verejnej proxy ponúka zoznam proxy SOCKS5 kandidátov pre ProxyAddr a ProxyPort. Fragment vytvára transportné vrstvy; aplikácia musí stále odoslať protokol, ktorý cieľ očakáva, a po dokončení socket zavrieť.

Zachovajte zamýšľané meno partnera

Koncový bod proxy patrí prvému spojeniu. SNI v TLS a overenie názvu hostiteľa sa týkajú example.com. Použitie názvu hostiteľa proxy v tejto fáze môže vyžiadať alebo overiť nesprávnu identitu.

Konfigurácia úložiska dôvery je ďalšou nezávislou požiadavkou. Použite zamýšľanú konfiguráciu CA aplikácie namiesto spätného volania dôverujúceho všetkému, skopírovaného z diagnostického príkladu.

Ak krok SOCKS zlyhá, zmena parametrov TLS to neopraví. Ak SOCKS uspeje a TLS zlyhá, uchovajte chybu certifikátu a názvu hostiteľa ako dôkaz, namiesto toho, aby ste ju považovali za všeobecný výpadok proxy.

Na názvoch modulov tiež záleží: IO::Socket::Socks a IO::Socket::SSL ponúkajú rôzne konštruktory a správanie pri aktualizácii. Holý TCP socket, ktorý len dosiahol proxy, ešte nedokončil vyjednávanie cieľa SOCKS.

Súvisiace články