ເປັນຫຍັງບຣາວເຊີອາດເຊື່ອງໜ້າປ້ອງກັນ HTTPS ຂອງ Squid

ໜ້າປ້ອງກັນທີ່ກຳນົດເອງຂອງພຣັອກຊີຈະສະແດງສຳລັບເວັບໄຊ HTTP. ສຳລັບເວັບໄຊ HTTPS, ບຣາວເຊີຈະສະແດງຄວາມຜິດພາດອຸໂມງແທນ. ການປ່ຽນແທນແມ່ແບບ HTML ອີກຄັ້ງອາດບໍ່ປ່ຽນຫຍັງເລີຍ.

ກັບພຣັອກຊີ HTTP ທີ່ຊັດເຈນ, ການເຂົ້າເບິ່ງ HTTPS ມັກຈະເລີ່ມດ້ວຍ CONNECT. ບຣາວເຊີຂໍໃຫ້ພຣັອກຊີເປີດອຸໂມງໄປຫາໂຮສ ແລະພອດ. ຖ້າ Squid ປະຕິເສດຄຳຮ້ອງນັ້ນ, ເຊສຊັນ TLS ຂອງເວັບໄຊຈະບໍ່ເລີ່ມຕົ້ນເລີຍ.

ການປະຕິເສດອາດມີສະຖານະ HTTP ແລະເນື້ອໃນຄຳຕອບ. ທ່ານສາມາດ ກວດສອບຄຳຕອບ CONNECT ທີ່ລົ້ມເຫຼວນັ້ນດ້ວຍ curl ໂດຍບໍ່ຂຶ້ນກັບໜ້າຄວາມຜິດພາດຂອງບຣາວເຊີ. ສິ່ງນີ້ບໍ່ຮຽກຮ້ອງໃຫ້ບຣາວເຊີສະແດງ HTML ທີ່ໃຫ້ໄວ້ເປັນໜ້າເວັບຂອງປາຍທາງ. ບຣາວເຊີອາດຖິ້ມເນື້ອຄວາມຜິດພາດ CONNECT ແລະໃຊ້ສ່ວນຕິດຕໍ່ຄວາມຜິດພາດພຣັອກຊີຂອງຕົນເອງ; ການສະແດງທີ່ແນ່ນອນຂຶ້ນກັບລູກຄ້າ.

ຖ້າການປະຕິເສດຂອງ Squid ມີເນື້ອ deny_info ທີ່ຕັ້ງໃຈແລ້ວ, ການແກ້ໄຂຂໍ້ຄວາມ ສະໄຕລ໌ຊີດ ຫຼືສິດທິຂອງໄຟລ໌ບໍ່ປ່ຽນແປງຂັ້ນຕອນຄຳຕອບທີ່ບຣາວເຊີຈັດການ. ເກັບສະຖານະການປະຕິເສດ ແລະບັນທຶກການເຂົ້າເຖິງໄວ້ ເພື່ອກຳນົດວ່າ CONNECT ຖືກປະຕິເສດ ແລະເປັນຫຍັງ. ໜ້າບຣາວເຊີທົ່ວໄປອາດເຊື່ອງລາຍລະອຽດນະໂຍບາຍ ໃນຂະນະທີ່ພຣັອກຊີບັງຄັບໃຊ້ກົດຢ່າງຖືກຕ້ອງ.

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