ຝ່າຍໃດຂອງພຣັອກຊີກວດສອບໄດ້ປະຕິເສດໃບຢັ້ງຢືນ?

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

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

ໃນການຈັດວາງແບບດັກຈັບ, ຕົວກາງຈະຢຸດ TLS ຂອງລູກຄ້າ ແລະ ສ້າງການເຊື່ອມຕໍ່ຂອງຕົນເອງຕໍ່ໄປ. ລູກຄ້າສາມາດຍອມຮັບໃບຢັ້ງຢືນທີ່ສະເໜີຢູ່ຝ່າຍຂອງຕົນ ໃນຂະນະທີ່ພຣັອກຊີປະຕິເສດໃບຢັ້ງຢືນທີ່ຕົນໄດ້ຮັບຈາກເວັບໄຊ.

ອ່ານຄວາມຜິດພາດຂອງຕົວກວດສອບ

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

ຕົວຢ່າງເຊັ່ນ Mitmproxy ບັນທຶກຕົວເລືອກຄວາມເຊື່ອໝັ້ນທາງເທິງແຍກຕ່າງຫາກ, ລວມທັງ ssl_verify_upstream_trusted_ca. ຜູ້ດູແລທີ່ເໝາະສົມສາມາດຕັ້ງຄ່າຄວາມເຊື່ອໝັ້ນທີ່ໄດ້ຮັບອະນຸມັດສຳລັບບໍລິການທາງເທິງ ໃນຂະນະທີ່ຮັກສາການກວດສອບໄວ້. ຜະລິດຕະພັນພຣັອກຊີອື່ນຕ້ອງການອິນເຕີເຟສທີ່ກົງກັນຂອງມັນ.

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

ອຸໂມງ CONNECT ທຳມະດາແຕກຕ່າງ

ອຸໂມງສົ່ງຕໍ່ທີ່ບໍ່ໂປ່ງໃສບໍ່ແບ່ງ TLS ຂອງປາຍທາງແບບນີ້. ໂດຍປົກກະຕິ ແອັບພລິເຄຊັນຈະເຈລະຈາ ແລະ ກວດສອບເຊສຊັນ TLS ຈາກປາຍຫາປາຍນັ້ນເອງ. ທຳອິດໃຫ້ກຳນົດວ່າການດັກຈັບເປັນສ່ວນໜຶ່ງຂອງເສັ້ນທາງແທ້ຫຼືບໍ່, ແທນທີ່ຈະໃຊ້ການຕັ້ງຄ່າພຣັອກຊີກວດສອບກັບຕົວກາງໃດໆ.

ບັນທຶກຜົນການກວດສອບທັງສອງແຍກກັນ. “ໃບຢັ້ງຢືນຂອງພຣັອກຊີເປັນທີ່ໜ້າເຊື່ອຖື” ຕອບຄຳຖາມຝ່າຍລູກຄ້າ; ມັນບໍ່ໄດ້ຢັ້ງຢືນວ່າພຣັອກຊີເຫັນຫຍັງເມື່ອເຊື່ອມຕໍ່ຂຶ້ນໄປ.