De SOCKS-ferbining en de TLS-ferbining hawwe ferskate taken. Krij earst in bytestream nei it doel fia SOCKS. Start dan TLS oer dy stream en identifisearje de doelside, net de proxy.

Foar in TLS-einpunt fan it HTTPS-type kin de opstelling wêze:

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

Foar in iepenbier HTTPS-doel op in tastiene iepenbiere-proxy-route biedt de SOCKS5-proxylist kandidaten foar ProxyAddr en ProxyPort. It fragmint set de transportlagen op; de applikaasje moat noch it protokol stjoere dat it doel ferwachtet en de socket slute as it klear is.

Behâld de bedoelde peer-namme

It proxy-einpunt heart by de earste ferbining. TLS SNI en hostnammeferifikaasje geane oer example.com. It brûken fan 'e hostnamme fan 'e proxy yn dy stap kin in ferkearde identiteit oanfreegje of ferifiearje.

Konfiguraasje fan 'e fertrouwensopslach is noch in ûnôfhinklike eask. Brûk de bedoelde CA-konfiguraasje fan 'e applikaasje ynstee fan in callback dy't alles fertrout, kopiearre út in diagnostysk foarbyld.

As de SOCKS-stap mislearret, sil it feroarjen fan TLS-parameters dat net oplosse. As SOCKS slagget en TLS mislearret, bewarje de sertifikaat- en hostnamme-flater as bewiis ynstee fan it as in algemiene proxy-útfal te behanneljen.

De module-nammen binne ek wichtich: IO::Socket::Socks en IO::Socket::SSL biede ferskate konstruktors en upgrade-gedrach. In rûge TCP-socket dy't allinnich de proxy berikte, hat de SOCKS-doelûnderhanneling noch net foltôge.

Relatearre artikelen