ລະບົບ SOCKS ທີ່ຍາວກວ່າບໍ່ໄດ້ປິດບັງຂັ້ນຕອນຕໍ່ໄປໂດຍອັດຕະໂນມັດ

ລະບົບປ່ຽນວ່າໃຜເປີດການເຊື່ອມຕໍ່ແຕ່ລະອັນ. ມັນບໍ່ເພີ່ມການເຂົ້າລະຫັດພຽງແຕ່ຍ້ອນວ່າເພີ່ມທີ່ຢູ່ SOCKS ອີກອັນໜຶ່ງໃສ່ບັນຊີ.

ພິຈາລະນາລູກຄ້າທີ່ສ້າງລະບົບນີ້ເອງ:

application → SOCKS A → SOCKS B → website

ມັນຂໍໃຫ້ A ເຊື່ອມຕໍ່ກັບ B ກ່ອນ. ຜ່ານສາຍນັ້ນ ມັນຈຶ່ງສາມາດເຈລະຈາກັບ B ກ່ຽວກັບການເຊື່ອມຕໍ່ກັບເວັບໄຊ. ຖ້າການຂົນສົ່ງຈາກລູກຄ້າໄປ A ຂົນທັງສອງການເຈລະຈາໂດຍບໍ່ມີການເຂົ້າລະຫັດ ຜູ້ສັງເກດທີ່ມີຄວາມສາມາດພຽງພໍໃນສາຍນັ້ນສາມາດອ່ານໄບຕ໌ຕັ້ງຄ່າທີ່ລູກຄ້າສົ່ງໄປ. ປາຍທາງ TCP ພາຍນອກບໍ່ແມ່ນຫຼັກຖານດຽວທີ່ເປັນໄປໄດ້ຂອງຜູ້ສັງເກດ.

ແຍກລະບົບອອກຈາກການແລກປ່ຽນແອັບພລິເຄຊັນທີ່ໄດ້ຮັບການປ້ອງກັນ

HTTPS ສາມາດປ້ອງກັນເນື້ອຫາແອັບພລິເຄຊັນຂອງເວັບໄຊຫຼັງຈາກເຊສຊັນ TLS ເລີ່ມຕົ້ນ. ມັນບໍ່ໄດ້ເຂົ້າລະຫັດຂໍ້ຄວາມຕັ້ງຄ່າ SOCKS ກ່ອນໜ້າຍ້ອນຫຼັງ. ການພິສູດຕົວຕົນຊື່ຜູ້ໃຊ້/ລະຫັດຜ່ານຂອງ SOCKS5 ກໍບໍ່ແມ່ນການຂົນສົ່ງທີ່ເຂົ້າລະຫັດ.

ການຈັດວາງທີ່ເຂົ້າລະຫັດລະຫວ່າງລູກຄ້າ ແລະ ຂັ້ນຕອນທຳອິດປ່ຽນການເບິ່ງເຫັນໃນສາຍນັ້ນ. ມັນຍັງມີຜູ້ດຳເນີນການ ແລະ ປາຍທາງອື່ນທີ່ຖືສາຍທີ່ຖອດລະຫັດແລ້ວ. ອະທິບາຍຂອບເຂດຄວາມເຊື່ອໝັ້ນນັ້ນ ແທນທີ່ຈະອ້າງວ່າລະບົບນີ້ຕິດຕາມບໍ່ໄດ້.

ເສັ້ນທາງຫຼັກທີ່ຕັ້ງຄ່າຢູ່ເຊີບເວີແມ່ນໂທໂປໂລຈີອື່ນ. ຖ້າ A ເລືອກ B ພາຍໃນ ລູກຄ້າອາດບໍ່ໄດ້ສົ່ງບັນຊີຕົວກາງທັງໝົດຜ່ານການເຊື່ອມຕໍ່ທຳອິດ. ຢ່າອ້າງວ່າທຸກລະບົບເປີດເຜີຍທຸກຂັ້ນຕອນຄືກັນ.

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