أضف TLS بعد أن يفتح Perl اتصال SOCKS

ضع IO::Socket::SSL فوق اتصال IO::Socket::Socks وتحقق من اسم مضيف الوجهة.

لاتصال SOCKS واتصال TLS وظيفتان مختلفتان. احصل أولًا على تدفق بايتات إلى الوجهة عبر SOCKS. ثم ابدأ TLS فوق ذلك التدفق، مع تحديد موقع الوجهة لا الوكيل.

بالنسبة إلى نقطة نهاية TLS من نوع HTTPS، يمكن أن يكون الترتيب كالتالي:

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. يبني هذا المقتطف طبقات النقل؛ ولا يزال على التطبيق إرسال البروتوكول الذي تتوقعه الوجهة وإغلاق المقبس عند الانتهاء.

احتفظ باسم النظير المقصود

نقطة نهاية الوكيل تخص الاتصال الأول. أما SNI في TLS والتحقق من اسم المضيف فيخصان example.com. واستخدام اسم مضيف الوكيل في تلك المرحلة قد يطلب هوية خاطئة أو يتحقق منها.

إعداد مخزن الثقة شرط مستقل آخر. استخدم إعداد CA المقصود في التطبيق بدلًا من دالة استدعاء تثق بكل شيء منسوخة من مثال تشخيصي.

إذا فشلت خطوة SOCKS، فلن يصلح تغيير معاملات TLS المشكلة. وإذا نجحت SOCKS وفشل TLS، فاحتفظ بـخطأ الشهادة واسم المضيف كدليل بدلًا من التعامل معه كعطل عام في الوكيل.

أسماء الوحدات مهمة أيضًا: فـ IO::Socket::Socks وIO::Socket::SSL يوفّران بواني وسلوك ترقية مختلفين. ومقبس TCP خام وصل إلى الوكيل فقط لم يكمل بعد تفاوض وجهة SOCKS.

مقالات ذات صلة