SOCKS savienojumam un TLS savienojumam ir dažādi uzdevumi. Vispirms iegūstiet baitu plūsmu uz galamērķi caur SOCKS. Pēc tam sāciet TLS virs šīs plūsmas, identificējot galamērķa vietni, nevis starpniekserveri.

HTTPS tipa TLS galapunktam izkārtojums var būt šāds:

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

Publiskam HTTPS mērķim atļautā publiska starpniekservera maršrutā SOCKS5 starpniekserveru saraksts piedāvā kandidātus ProxyAddr un ProxyPort vērtībām. Šis fragments izveido transporta slāņus; lietojumprogrammai joprojām jānosūta galamērķa gaidītais protokols un pēc tam jāaizver ligzda.

Saglabājiet paredzēto partnera nosaukumu

Starpniekservera galapunkts pieder pirmajam savienojumam. TLS SNI un resursdatora nosaukuma pārbaude attiecas uz example.com. Starpniekservera resursdatora nosaukuma izmantošana šajā posmā var pieprasīt vai pārbaudīt nepareizu identitāti.

Uzticības krātuves konfigurācija ir vēl viena neatkarīga prasība. Izmantojiet lietojumprogrammas paredzēto CA konfigurāciju, nevis visam uzticīgu atzvanīšanas funkciju, kas nokopēta no diagnostikas piemēra.

Ja SOCKS solis neizdodas, TLS parametru maiņa to nelabos. Ja SOCKS izdodas un TLS neizdodas, saglabājiet sertifikāta un resursdatora nosaukuma kļūdu kā pierādījumu, nevis uzskatiet to par vispārēju starpniekservera traucējumu.

Arī moduļu nosaukumi ir svarīgi: IO::Socket::Socks un IO::Socket::SSL piedāvā atšķirīgus konstruktorus un jaunināšanas uzvedību. Neapstrādāta TCP ligzda, kas tikai sasniedza starpniekserveri, vēl nav pabeigusi SOCKS galamērķa sarunas.

Saistītie raksti