Sambungan SOCKS dan sambungan TLS mempunyai tugas berbeza. Mula-mula dapatkan aliran bait ke destinasi melalui SOCKS. Kemudian mulakan TLS di atas aliran itu, dengan mengenal pasti laman web destinasi dan bukan proksi.

Untuk titik akhir TLS gaya HTTPS, susunannya boleh jadi:

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

Untuk sasaran HTTPS awam pada laluan proksi awam yang dibenarkan, senarai proksi SOCKS5 menawarkan calon untuk ProxyAddr dan ProxyPort. Serpihan ini menyediakan lapisan pengangkutan; aplikasi masih perlu menghantar protokol yang dijangka oleh destinasi dan menutup soket apabila selesai.

Kekalkan nama rakan yang dimaksudkan

Titik akhir proksi milik sambungan pertama. SNI TLS dan pengesahan nama hos berkaitan dengan example.com. Menggunakan nama hos proksi pada peringkat itu boleh meminta atau mengesahkan identiti yang salah.

Konfigurasi stor kepercayaan ialah satu lagi keperluan bebas. Gunakan konfigurasi CA yang dimaksudkan oleh aplikasi dan bukan callback yang mempercayai segala-galanya, yang disalin daripada contoh diagnostik.

Jika langkah SOCKS gagal, menukar parameter TLS tidak akan membaikinya. Jika SOCKS berjaya dan TLS gagal, simpan ralat sijil dan nama hos sebagai bukti dan bukannya menganggapnya sebagai gangguan proksi biasa.

Nama modul juga penting: IO::Socket::Socks dan IO::Socket::SSL menawarkan pembina dan tingkah laku peningkatan yang berbeza. Soket TCP mentah yang hanya sampai ke proksi belum menyelesaikan rundingan destinasi SOCKS.

Artikel berkaitan