Lägg till TLS efter att Perl har öppnat SOCKS-anslutningen

Lägg IO::Socket::SSL ovanpå en IO::Socket::Socks-anslutning och verifiera värdnamnet för målet.

SOCKS-anslutningen och TLS-anslutningen har olika uppgifter. Skaffa först en byte-ström till målet via SOCKS. Starta sedan TLS ovanpå den strömmen och identifiera målwebbplatsen i stället för proxyn.

För en TLS-slutpunkt av HTTPS-typ kan upplägget vara:

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

För ett offentligt HTTPS-mål på en tillåten offentlig proxyväg erbjuder SOCKS5-proxylistan kandidater för ProxyAddr och ProxyPort. Utdraget bygger transportlagren; programmet måste fortfarande skicka det protokoll målet förväntar sig och stänga socketen när det är klart.

Behåll det avsedda peer-namnet

Proxy-slutpunkten tillhör den första anslutningen. TLS SNI och värdnamnsverifiering gäller example.com. Att använda proxyns värdnamn i det skedet kan begära eller verifiera fel identitet.

Konfiguration av förtroendelagret är ett annat oberoende krav. Använd programmets avsedda CA-konfiguration i stället för en callback som litar på allt, kopierad från ett diagnostiskt exempel.

Om SOCKS-steget misslyckas löser ändrade TLS-parametrar inte det. Om SOCKS lyckas och TLS misslyckas, spara certifikat- och värdnamnsfelet som bevis i stället för att behandla det som ett allmänt proxyavbrott.

Modulnamnen spelar också roll: IO::Socket::Socks och IO::Socket::SSL erbjuder olika konstruktorer och uppgraderingsbeteende. En rå TCP-socket som bara nådde proxyn har ännu inte slutfört SOCKS-målförhandlingen.

Relaterade artiklar