SOCKS veza i TLS veza imaju različite zadaće. Najprije pribavite tok bajtova do odredišta kroz SOCKS. Zatim pokrenite TLS preko tog toka, identificirajući odredišno web-mjesto, a ne proxy.

Za TLS završnu točku tipa HTTPS raspored može biti:

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();

Za javni HTTPS cilj na dopuštenoj ruti javnog proxyja popis SOCKS5 proxyja nudi kandidate za ProxyAddr i ProxyPort. Isječak uspostavlja transportne slojeve; aplikacija ipak mora poslati protokol koji odredište očekuje i zatvoriti socket kada završi.

Zadržite namjeravano ime partnera

Proxy završna točka pripada prvoj vezi. TLS SNI i provjera imena hosta odnose se na example.com. Korištenje imena hosta proxyja u toj fazi može zatražiti ili provjeriti pogrešan identitet.

Konfiguracija spremišta povjerenja još je jedan neovisan zahtjev. Koristite namjeravanu CA konfiguraciju aplikacije umjesto povratnog poziva koji vjeruje svemu, kopiranog iz dijagnostičkog primjera.

Ako SOCKS korak ne uspije, promjena TLS parametara to neće popraviti. Ako SOCKS uspije, a TLS ne uspije, sačuvajte pogrešku certifikata i imena hosta kao dokaz umjesto da je tretirate kao opći prekid proxyja.

Imena modula također su važna: IO::Socket::Socks i IO::Socket::SSL nude različite konstruktore i ponašanje nadogradnje. Sirovi TCP socket koji je samo stigao do proxyja još nije dovršio SOCKS pregovaranje odredišta.

Povezani članci