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-тэй холбоотой. Тэр үе шатанд проксигийн хост нэрийг ашиглах нь буруу таних тэмдгийг хүсэх эсвэл шалгаж болно.

Итгэлийн сангийн тохиргоо нь өөр нэг бие даасан шаардлага юм. Оношлогооны жишээнээс хуулсан бүхэнд итгэдэг callback-ийн оронд програмын зорьсон CA тохиргоог ашиглана уу.

Хэрэв SOCKS алхам бүтэлгүйтвэл TLS параметрийг өөрчлөх нь үүнийг засахгүй. Хэрэв SOCKS амжилттай болж, TLS бүтэлгүйтвэл сертификат болон хост нэрийн алдааг нотолгоо болгон хадгалж, ерөнхий проксийн саатал гэж бүү үзээрэй.

Модулийн нэр ч бас чухал: IO::Socket::Socks болон IO::Socket::SSL нь өөр өөр конструктор, шинэчлэлтийн зан төлөвийг санал болгодог. Зөвхөн проксид хүрсэн түүхий TCP сокет нь SOCKS очих газрын хэлэлцээрийг хараахан дуусгаагүй байна.

Холбоотой нийтлэлүүд