Aldoni TLS post kiam Perl malfermis la SOCKS-konekton

Metu IO::Socket::SSL super IO::Socket::Socks-konekton kaj kontrolu la celan gastigantnomon.

La SOCKS-konekto kaj la TLS-konekto havas malsamajn taskojn. Unue akiru bitfluejon al la celo per SOCKS. Poste startigu TLS super tiu fluejo, identigante la celan retejon anstataŭ la prokuron.

Por TLS-fina punkto de la HTTPS-tipo, la aranĝo povas esti:

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

Por publika HTTPS-celo sur permesita publika prokura vojo, la SOCKS5-prokurlisto proponas kandidatojn por ProxyAddr kaj ProxyPort. La fragmento starigas la transportajn tavolojn; la aplikaĵo ankoraŭ devas sendi la protokolon atendatan de la celo kaj fermi la ingon kiam ĝi finiĝas.

Konservu la intencitan kunulan nomon

La prokura fina punkto apartenas al la unua konekto. TLS SNI kaj gastigantnoma kontrolo koncernas example.com. Uzi la prokuran gastigantnomon en tiu stadio povas peti aŭ kontroli malĝustan identecon.

Agordo de la fido-deponejo estas alia sendependa postulo. Uzu la intencitan CA-agordon de la aplikaĵo anstataŭ reago kiu fidas ĉion, kopiita el diagnoza ekzemplo.

Se la SOCKS-paŝo malsukcesas, ŝanĝi TLS-parametrojn ne riparos ĝin. Se SOCKS sukcesas kaj TLS malsukcesas, konservu la atestilan kaj gastigantnoman eraron kiel pruvon anstataŭ trakti ĝin kiel ĝeneralan prokuran paneon.

Ankaŭ la modulnomoj gravas: IO::Socket::Socks kaj IO::Socket::SSL prezentas malsamajn konstruilojn kaj ĝisdatigan konduton. Kruda TCP-ingo kiu nur atingis la prokuron ankoraŭ ne finis la SOCKS-celan intertraktadon.

Rilataj artikoloj