Legg til TLS etter at Perl har åpnet SOCKS-tilkoblingen
Legg IO::Socket::SSL over en IO::Socket::Socks-tilkobling og verifiser vertsnavnet til målet.
SOCKS-tilkoblingen og TLS-tilkoblingen har forskjellige oppgaver. Skaff først en bytestrøm til målet via SOCKS. Start deretter TLS over den strømmen, og identifiser målområdet i stedet for proxyen.
For et TLS-endepunkt av HTTPS-typen kan oppsettet være:
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();
For et offentlig HTTPS-mål på en tillatt offentlig proxy-rute tilbyr SOCKS5-proxylisten kandidater for ProxyAddr og ProxyPort. Utdraget etablerer transportlagene; applikasjonen må fortsatt sende protokollen målet forventer og lukke sockelen når den er ferdig.
Behold det tiltenkte peer-navnet
Proxy-endepunktet tilhører den første tilkoblingen. TLS SNI og vertsnavnverifisering gjelder example.com. Å bruke proxyens vertsnavn på det stadiet kan be om eller verifisere feil identitet.
Konfigurasjon av tillitslageret er et annet uavhengig krav. Bruk applikasjonens tiltenkte CA-konfigurasjon i stedet for en callback som stoler på alt, kopiert fra et diagnostisk eksempel.
Hvis SOCKS-trinnet mislykkes, hjelper det ikke å endre TLS-parametere. Hvis SOCKS lykkes og TLS mislykkes, ta vare på sertifikat- og vertsnavnfeilen som bevis i stedet for å behandle den som et generelt proxy-utfall.
Modulnavnene betyr også noe: IO::Socket::Socks og IO::Socket::SSL tilbyr forskjellige konstruktører og oppgraderingsadferd. En rå TCP-socket som bare nådde proxyen, har ennå ikke fullført SOCKS-målavtalen.