পার্ল 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 গন্তব্য-সমঝোতা সম্পূর্ণ করেনি।