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.

Relaterte artikler