Die SOCKS-verbinding en die TLS-verbinding het verskillende take. Kry eers 'n greutstroom na die bestemming deur SOCKS. Begin dan TLS oor daardie stroom en identifiseer die bestemmingswebwerf, nie die proxy nie.

Vir 'n TLS-eindpunt van die HTTPS-tipe kan die reëling so lyk:

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

Vir 'n openbare HTTPS-teiken op 'n toegelate openbare-proxy-roete bied die SOCKS5-proxylys kandidate vir ProxyAddr en ProxyPort. Die fragment bou die vervoerlae; die toepassing moet steeds die protokol stuur wat die bestemming verwag en die sokkie sluit wanneer klaar.

Behou die beoogde eweknie-naam

Die proxy-eindpunt hoort by die eerste verbinding. TLS SNI en gasheernaamverifikasie raak example.com. Om die proxy se gasheernaam op daardie stadium te gebruik kan die verkeerde identiteit aanvra of verifieer.

Trust-store-konfigurasie is nog 'n onafhanklike vereiste. Gebruik die toepassing se bedoelde CA-konfigurasie eerder as 'n callback wat alles vertrou, gekopieer uit 'n diagnostiese voorbeeld.

As die SOCKS-stap misluk, sal verandering van TLS-parameters dit nie regmaak nie. As SOCKS slaag en TLS misluk, hou die sertifikaat- en gasheernaamfout as bewys in plaas daarvan om dit as 'n algemene proxy-onderbreking te behandel.

Die module-name maak ook saak: IO::Socket::Socks en IO::Socket::SSL het verskillende konstruktors en opgraderingsgedrag. 'n Rou TCP-sokkie wat net die proxy bereik het, het nog nie die SOCKS-bestemmingsonderhandeling voltooi nie.

Verwante artikels