افزودن 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 موردنظر برنامه استفاده کنید، نه از یک callback که به همه چیز اعتماد می‌کند و از یک نمونه تشخیصی کپی شده است.

اگر مرحله SOCKS شکست بخورد، تغییر پارامترهای TLS آن را درست نمی‌کند. اگر SOCKS موفق و TLS ناموفق باشد، خطای گواهی و نام میزبان را به‌عنوان شاهد نگه دارید، نه اینکه آن را یک قطعی عمومی پروکسی بدانید.

نام ماژول‌ها هم مهم است: IO::Socket::Socks و IO::Socket::SSL سازنده‌ها و رفتار ارتقای متفاوتی دارند. یک سوکت خام TCP که فقط به پروکسی رسیده هنوز مذاکره مقصد SOCKS را کامل نکرده است.

مقالات مرتبط