De SOCKS-verbinding en de TLS-verbinding hebben verschillende taken. Haal eerst een bytestroom naar de bestemming via SOCKS. Start daarna TLS over die stroom en identificeer de bestemmingswebsite in plaats van de proxy.

Voor een TLS-eindpunt in HTTPS-stijl kan de opzet zijn:

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

Voor een openbaar HTTPS-doel op een toegestane openbare-proxyroute biedt de SOCKS5-proxylijst kandidaten voor ProxyAddr en ProxyPort. Het fragment legt de transportlagen aan; de toepassing moet nog steeds het protocol sturen dat de bestemming verwacht en de socket sluiten wanneer ze klaar is.

Behoud de bedoelde peernaam

Het proxy-eindpunt hoort bij de eerste verbinding. TLS SNI en hostnaamverificatie betreffen example.com. De hostnaam van de proxy in die fase gebruiken kan een verkeerde identiteit aanvragen of verifiëren.

Configuratie van de vertrouwensopslag is een andere onafhankelijke vereiste. Gebruik de bedoelde CA-configuratie van de toepassing in plaats van een callback die alles vertrouwt, gekopieerd uit een diagnostisch voorbeeld.

Als de SOCKS-stap mislukt, lost het wijzigen van TLS-parameters dat niet op. Als SOCKS slaagt en TLS mislukt, bewaar de certificaat- en hostnaamfout als bewijs in plaats van die als een algemene proxy-storing te behandelen.

De modulenamen zijn ook belangrijk: IO::Socket::Socks en IO::Socket::SSL bieden verschillende constructors en upgrade-gedrag. Een ruwe TCP-socket die alleen de proxy bereikte, heeft de SOCKS-bestemmingsonderhandeling nog niet voltooid.

Gerelateerde artikelen