Voeg TLS by nadat Perl die SOCKS-verbinding geopen het
Plaas IO::Socket::SSL oor 'n IO::Socket::Socks-verbinding en verifieer die gasheernaam van die bestemming.
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.