Dodajte TLS, potem ko je Perl odprl povezavo SOCKS
Položite IO::Socket::SSL na povezavo IO::Socket::Socks in preverite ime gostitelja cilja.
Povezava SOCKS in povezava TLS imata različne naloge. Najprej pridobite bajtni tok do cilja prek SOCKS. Nato zaženite TLS na tem toku in prepoznajte ciljno spletno mesto, ne posrednika.
Za končno točko TLS v slogu HTTPS je razporeditev lahko naslednja:
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();
Za javni cilj HTTPS na dovoljeni poti javnega posrednika seznam posrednikov SOCKS5 ponuja kandidate za ProxyAddr in ProxyPort. Izsek vzpostavi transportne plasti; aplikacija mora še vedno poslati protokol, ki ga cilj pričakuje, in ob koncu zapreti vtičnico.
Ohranite predvideno ime partnerja
Končna točka posrednika pripada prvi povezavi. SNI v TLS in preverjanje imena gostitelja se nanašata na example.com. Uporaba imena gostitelja posrednika v tej fazi lahko zahteva ali preveri napačno identiteto.
Konfiguracija shrambe zaupanja je še ena neodvisna zahteva. Uporabite predvideno konfiguracijo CA aplikacije namesto povratnega klica, ki zaupa vsemu, kopiranega iz diagnostičnega primera.
Če korak SOCKS ne uspe, sprememba parametrov TLS tega ne bo popravila. Če SOCKS uspe in TLS ne uspe, shranite napako potrdila in imena gostitelja kot dokaz, namesto da bi jo obravnavali kot splošno okvaro posrednika.
Tudi imena modulov so pomembna: IO::Socket::Socks in IO::Socket::SSL ponujata različne konstruktorje in vedenje pri nadgradnji. Surova vtičnica TCP, ki je le dosegla posrednika, še ni dokončala pogajanj o cilju SOCKS.