پرل کے SOCKS کنکشن کھولنے کے بعد TLS شامل کریں

SOCKS کنکشن اور TLS کنکشن کے کام مختلف ہیں۔ پہلے SOCKS کے ذریعے منزل تک بائٹ اسٹریم حاصل کریں۔ پھر اسی اسٹریم پر TLS شروع کریں، پراکسی کی بجائے منزل کی ویب سائٹ کی شناخت کرتے ہوئے۔

HTTPS طرز کے TLS اینڈ پوائنٹ کے لیے ترتیب یوں ہو سکتی ہے:

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

اجازت یافتہ عوامی پراکسی راستے پر عوامی HTTPS ہدف کے لیے SOCKS5 پراکسی فہرست ProxyAddr اور ProxyPort کے لیے امیدوار پیش کرتی ہے۔ یہ حصہ نقل و حمل کی تہیں قائم کرتا ہے؛ ایپلیکیشن کو اب بھی وہ پروٹوکول بھیجنا ہوگا جس کی منزل توقع کرتی ہے اور ختم ہونے پر ساکٹ بند کرنا ہوگا۔

مقصود ہم منصب نام برقرار رکھیں

پراکسی اینڈ پوائنٹ پہلے کنکشن کا ہے۔ TLS SNI اور ہوسٹ نام کی تصدیق example.com سے متعلق ہے۔ اس مرحلے پر پراکسی کا ہوسٹ نام استعمال کرنے سے غلط شناخت طلب یا تصدیق ہو سکتی ہے۔

ٹرسٹ اسٹور کی ترتیب ایک اور خودمختار تقاضا ہے۔ تشخیصی مثال سے نقل کیے گئے ہر چیز پر بھروسا کرنے والے کال بیک کی بجائے ایپلیکیشن کی مقصود CA ترتیب استعمال کریں۔

اگر SOCKS مرحلہ ناکام ہو تو TLS پیرامیٹرز بدلنے سے وہ درست نہیں ہوگا۔ اگر SOCKS کامیاب ہو اور TLS ناکام ہو تو سرٹیفکیٹ اور ہوسٹ نام کی خرابی کو بطور ثبوت رکھیں، اسے عام پراکسی خرابی نہ سمجھیں۔

ماڈیول کے نام بھی اہم ہیں: IO::Socket::Socks اور IO::Socket::SSL مختلف کنسٹرکٹر اور اپ گریڈ رویہ دیتے ہیں۔ صرف پراکسی تک پہنچنے والا خام TCP ساکٹ ابھی SOCKS منزل کے مذاکرات مکمل نہیں کر سکا۔