A SOCKS-kapcsolat és a TLS-kapcsolat külön feladatot lát el. Először szerezzen bájtfolyamot a célhoz SOCKS-on keresztül. Ezután indítsa el a TLS-t e folyam fölött, a célwebhelyet azonosítva a proxy helyett.

HTTPS-jellegű TLS-végpont esetén az elrendezés a következő lehet:

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

Egy engedélyezett nyilvános proxy-útvonalon lévő nyilvános HTTPS-célhoz a SOCKS5 proxy lista kínál jelölteket a ProxyAddr és a ProxyPort számára. A részlet felépíti a szállítási rétegeket; az alkalmazásnak továbbra is el kell küldenie a cél által várt protokollt, és a végén be kell zárnia a socketet.

Tartsa meg a szándékolt partnernevet

A proxy végpontja az első kapcsolathoz tartozik. A TLS SNI és a hosztnév-ellenőrzés a következőre vonatkozik: example.com. A proxy hosztnevének használata ebben a szakaszban hibás identitást kérhet vagy ellenőrizhet.

A bizalmi tároló konfigurációja egy másik független követelmény. Használja az alkalmazás szándékolt CA-konfigurációját a mindent megbízó, diagnosztikai példából másolt visszahívás helyett.

Ha a SOCKS lépés meghiúsul, a TLS-paraméterek módosítása nem javítja meg. Ha a SOCKS sikerül és a TLS meghiúsul, őrizze meg a tanúsítvány- és hosztnév-hibát bizonyítékként, ahelyett hogy általános proxy-kiesésként kezelné.

A modulnevek is számítanak: az IO::Socket::Socks és az IO::Socket::SSL eltérő konstruktorokat és frissítési viselkedést kínál. Egy nyers TCP-socket, amely csak a proxyig jutott el, még nem fejezte be a SOCKS cél-tárgyalást.

Kapcsolódó cikkek