SOCKS-tilkoplinga og TLS-tilkoplinga har ulike oppgåver. Skaff først ein bytestraum til målet via SOCKS. Start deretter TLS over den straumen, og identifiser målområdet i staden for proxyen.

For eit TLS-endepunkt av HTTPS-typen kan oppsettet vere:

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 eit offentleg HTTPS-mål på ei tillaten offentleg proxy-rute tilbyr SOCKS5-proxylista kandidatar for ProxyAddr og ProxyPort. Utdraget etablerer transportlaga; applikasjonen må framleis senda protokollen målet ventar og lukka sockelen når ho er ferdig.

Hald på det tiltenkte peer-namnet

Proxy-endepunktet høyrer til den første tilkoplinga. TLS SNI og vertsnamnstadfesting gjeld example.com. Å bruka vertsnamnet til proxyen på det stadiet kan be om eller stadfesta feil identitet.

Konfigurasjon av tillitslageret er eit anna uavhengig krav. Bruk den tiltenkte CA-konfigurasjonen til applikasjonen i staden for ein callback som stolar på alt, kopiert frå eit diagnostisk døme.

Viss SOCKS-steget mislukkast, hjelper det ikkje å endra TLS-parametrar. Viss SOCKS lukkast og TLS mislukkast, ta vare på sertifikat- og vertsnamnfeilen som prov i staden for å handsama han som eit generelt proxy-utfall.

Modulnamna har òg noko å seia: IO::Socket::Socks og IO::Socket::SSL tilbyr ulike konstruktørar og oppgraderingsåtferd. Ein rå TCP-socket som berre nådde proxyen, har enno ikkje fullført SOCKS-målavtalen.

Relaterte artiklar