Legg til TLS etter at Perl har åpnet SOCKS-tilkoblingen

Legg IO::Socket::SSL oppå en IO::Socket::Socks-tilkobling og verifiser vertsnavnet til destinasjonen.

SOCKS-tilkoblingen og TLS-tilkoblingen har ulike oppgaver. Få først en bytestrøm til destinasjonen gjennom SOCKS. Start så TLS oppå den strømmen, og identifiser destinasjonsnettstedet i stedet for proxyen.

For et TLS-endepunkt i HTTPS-stil kan oppsettet se slik ut:

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å likevel sende protokollen destinasjonen forventer og lukke socketen når den er ferdig.

Behold det tiltenkte peer-navnet

Proxy-endepunktet hører til den første tilkoblingen. TLS SNI og vertsnavnverifisering gjelder example.com. Å bruke proxyens vertsnavn på det trinnet kan be om eller verifisere feil identitet.

Konfigurasjon av tillitslageret er et annet uavhengig krav. Bruk applikasjonens tiltenkte CA-konfigurasjon i stedet for en tilbakeringing som stoler på alt, kopiert fra et diagnostisk eksempel.

Hvis SOCKS-trinnet feiler, hjelper det ikke å endre TLS-parametere. Hvis SOCKS lykkes og TLS feiler, ta vare på sertifikat- og vertsnavnfeilen som bevis i stedet for å behandle den som et generelt proxy-avbrudd.

Modulnavnene betyr også noe: IO::Socket::Socks og IO::Socket::SSL tilbyr forskjellige konstruktører og oppgraderingsoppførsel. En rå TCP-socket som bare nådde proxyen, har ennå ikke fullført SOCKS-destinasjonsforhandlingen.

Relaterte artikler