Perl द्वारा 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 गंतव्य वार्ता पूरी नहीं कर चुका है।