पर्लले 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 गन्तव्य वार्ता पूरा गरेको छैन।