ການເຊື່ອມຕໍ່ 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. ສ່ວນນີ້ສ້າງຊັ້ນການຂົນສົ່ງ; ແອັບພລິເຄຊັນຍັງຕ້ອງສົ່ງໂປຣໂຕຄອນທີ່ປາຍທາງຄາດຫວັງ ແລະ ປິດຊອກເກັດເມື່ອສຳເລັດ.

ຮັກສາຊື່ຄູ່ທີ່ຕັ້ງໃຈໄວ້

ຈຸດປາຍພຣັອກຊີເປັນຂອງການເຊື່ອມຕໍ່ທຳອິດ. TLS SNI ແລະ ການກວດສອບຊື່ໂຮສກ່ຽວຂ້ອງກັບ example.com. ການໃຊ້ຊື່ໂຮສຂອງພຣັອກຊີໃນຂັ້ນນັ້ນອາດຮ້ອງຂໍ ຫຼື ກວດສອບຕົວຕົນທີ່ຜິດ.

ການຕັ້ງຄ່າບ່ອນເກັບຄວາມໄວ້ວາງໃຈເປັນຂໍ້ກຳນົດອິດສະຫຼະອີກຢ່າງໜຶ່ງ. ໃຊ້ການຕັ້ງຄ່າ CA ທີ່ແອັບພລິເຄຊັນຕັ້ງໃຈ ແທນ callback ທີ່ໄວ້ວາງໃຈທຸກຢ່າງ ທີ່ຄັດລອກມາຈາກຕົວຢ່າງການວິນິດໄສ.

ຖ້າຂັ້ນ SOCKS ລົ້ມເຫຼວ, ການປ່ຽນພາຣາມິເຕີ TLS ຈະບໍ່ແກ້ໄຂມັນ. ຖ້າ SOCKS ສຳເລັດແລ້ວ TLS ລົ້ມເຫຼວ, ໃຫ້ເກັບ ຂໍ້ຜິດພາດຂອງໃບຮັບຮອງ ແລະ ຊື່ໂຮສ ໄວ້ເປັນຫຼັກຖານ ແທນທີ່ຈະຖືວ່າເປັນການຂັດຂ້ອງຂອງພຣັອກຊີທົ່ວໄປ.

ຊື່ໂມດູນກໍສຳຄັນ: IO::Socket::Socks ແລະ IO::Socket::SSL ມີຄອນສະຕຣັກເຕີ ແລະ ພຶດຕິກຳການອັບເກຣດຕ່າງກັນ. ຊອກເກັດ TCP ດິບໆທີ່ພຽງແຕ່ໄປຮອດພຣັອກຊີ ຍັງບໍ່ໄດ້ສຳເລັດການເຈລະຈາປາຍທາງ SOCKS ເທື່ອ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ