Přidejte TLS poté, co Perl otevřel SOCKS spojení

Vrstvěte IO::Socket::SSL nad spojení IO::Socket::Socks a ověřte název hostitele cíle.

SOCKS spojení a TLS spojení mají různé úlohy. Nejprve získejte bajtový proud k cíli přes SOCKS. Poté spusťte TLS nad tímto proudem a identifikujte cílový web, nikoli proxy.

Pro koncový bod TLS typu HTTPS může uspořádání vypadat takto:

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

Pro veřejný cíl HTTPS na povolené trase veřejné proxy nabízí seznam proxy SOCKS5 kandidáty pro ProxyAddr a ProxyPort. Fragment vytváří transportní vrstvy; aplikace musí stále odeslat protokol, který cíl očekává, a po dokončení socket zavřít.

Zachovejte zamýšlené jméno protějšku

Koncový bod proxy patří prvnímu spojení. SNI v TLS a ověření názvu hostitele se týkají example.com. Použití názvu hostitele proxy v této fázi může vyžádat nebo ověřit nesprávnou identitu.

Konfigurace úložiště důvěry je dalším nezávislým požadavkem. Použijte zamýšlenou konfiguraci CA aplikace místo callbacku důvěřujícího všemu, zkopírovaného z diagnostického příkladu.

Pokud krok SOCKS selže, změna parametrů TLS to neopraví. Pokud SOCKS uspěje a TLS selže, uchovejte chybu certifikátu a názvu hostitele jako důkaz, místo abyste ji považovali za obecný výpadek proxy.

Na názvech modulů také záleží: IO::Socket::Socks a IO::Socket::SSL nabízejí různé konstruktory a chování při upgradu. Holý TCP socket, který jen dosáhl proxy, ještě nedokončil vyjednávání cíle SOCKS.

Související články