Tilføj TLS, når Perl har åbnet SOCKS-forbindelsen
Læg IO::Socket::SSL oven på en IO::Socket::Socks-forbindelse, og verificér destinationsværtens navn.
SOCKS-forbindelsen og TLS-forbindelsen har forskellige opgaver. Skaf først en bytestrøm til destinationen via SOCKS. Start derefter TLS oven på den strøm og identificér destinationswebstedet frem for proxyen.
For et TLS-endepunkt af HTTPS-typen kan opsætningen 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 offentligt HTTPS-mål på en tilladt offentlig proxy-rute tilbyder SOCKS5-proxylisten kandidater til ProxyAddr og ProxyPort. Uddraget etablerer transportlagene; programmet skal stadig sende den protokol, destinationen forventer, og lukke socket'en, når det er færdigt.
Behold det tilsigtede peer-navn
Proxy-endepunktet hører til den første forbindelse. TLS SNI og værtsnavnverifikation angår example.com. Brug af proxyens værtsnavn på det trin kan anmode om eller verificere en forkert identitet.
Konfiguration af tillidslageret er endnu et uafhængigt krav. Brug programmets tilsigtede CA-konfiguration i stedet for et callback, der stoler på alt, kopieret fra et diagnostisk eksempel.
Hvis SOCKS-trinnet mislykkes, hjælper det ikke at ændre TLS-parametre. Hvis SOCKS lykkes, og TLS mislykkes, skal du gemme certifikat- og værtsnavnfejlen som bevis i stedet for at behandle den som et generelt proxy-nedbrud.
Modulnavnene betyder også noget: IO::Socket::Socks og IO::Socket::SSL tilbyder forskellige konstruktører og opgraderingsadfærd. En rå TCP-socket, der blot nåede proxyen, har endnu ikke afsluttet SOCKS-destinationsforhandlingen.