დაამატეთ TLS მას შემდეგ, რაც Perl-მა SOCKS კავშირი გახსნა
გადააფარეთ IO::Socket::SSL IO::Socket::Socks კავშირს და გადაამოწმეთ დანიშნულების ჰოსტის სახელი.
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 კონფიგურაცია და არა ყველაფრის მიმართ მოდუნებული callback, დიაგნოსტიკური მაგალითიდან კოპირებული.
თუ SOCKS საფეხური ვერ შესრულდა, TLS პარამეტრების შეცვლა ამას არ გამოასწორებს. თუ SOCKS წარმატებულია და TLS ვერ შესრულდა, შეინახეთ სერტიფიკატისა და ჰოსტის სახელის შეცდომა მტკიცებულებად, ნაცვლად იმისა, რომ ის ზოგად პროქსის გათიშვად ჩათვალოთ.
მოდულების სახელებსაც აქვს მნიშვნელობა: IO::Socket::Socks და IO::Socket::SSL სხვადასხვა კონსტრუქტორსა და განახლების ქცევას გვთავაზობს. მხოლოდ პროქსიმდე მიღწეულ ნედლ TCP სოკეტს ჯერ არ დაუსრულებია SOCKS დანიშნულების მოლაპარაკება.