WRONG_VERSION_NUMBER ກັບພຣັອກຊີ: ກວດ HTTP ກັບ HTTPS

ຂໍ້ຜິດພາດບອກວ່າ “ລຸ້ນຜິດ” ດັ່ງນັ້ນຈຶ່ງຢາກເລີ່ມປ່ຽນລຸ້ນ TLS. ກັບພຣັອກຊີ ໃຫ້ກວດຄວາມເປັນໄປໄດ້ທີ່ເກີດກ່ອນ: ລູກຄ້າໄດ້ສົ່ງການຈັບມື TLS ໄປຫາພອດທີ່ລໍຖ້າ HTTP ທຳມະດາບໍ?

ປາຍທາງຢ່າງ https://example.com/ ແລະ ພຣັອກຊີຢ່າງ http://proxy.example:8080 ເປັນຄູ່ທຳມະດາ. ການປ່ຽນ URL ທີສອງເປັນ HTTPS ບອກລູກຄ້າໃຫ້ເຂົ້າລະຫັດການສົນທະນາກັບພຣັອກຊີເອງ. ມັນບໍ່ແມ່ນຄຳສັ່ງໃຫ້ອະນຸຍາດເວັບໄຊ HTTPS.

ຊອກຫາການສົນທະນາ TLS ທຳອິດ

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

ຕົວວິເຄາະ TLS ທີ່ໄດ້ຮັບໜ້າຂໍ້ຜິດພາດ HTTP ຫຼື ຂໍ້ຄວາມທຳມະດາອື່ນ ອາດລາຍງານຂໍ້ຜິດພາດໂປຣໂຕຄໍ. ຖ້ອຍຄຳນັ້ນບໍ່ໄດ້ຢືນຢັນວ່າເວັບໄຊຮອງຮັບລຸ້ນ TLS ໃດ, ຫຼືແມ່ນແຕ່ວ່າໄດ້ຕິດຕໍ່ເວັບໄຊແລ້ວ.

1. ບັນທຶກ URL ຂອງພຣັອກຊີ ລວມທັງ scheme ຂອງມັນ ແລະ ໂປຣໂຕຄໍທີ່ເອກະສານກຳນົດໄວ້ຂອງຈຸດປາຍທາງ.
2. ຊອກຫາວ່າຄວາມລົ້ມເຫຼວເກີດກ່ອນຄຳຕອບ CONNECT, ລະຫວ່າງ TLS ຂອງປາຍທາງ, ຫຼື ຕອນກວດສອບໃບຮັບຮອງຂອງພຣັອກຊີເອງ.
3. ກວດສອບລຸ້ນຕົວຈິງຂອງລູກຄ້າ ແລະ ຕົວອີງໃສ່ ເມື່ອປຽບທຽບວິທີແກ້ເກົ່າ. ການຈັດຕັ້ງພຣັອກຊີແບບເກົ່າບາງເທື່ອຖື scheme ຕ່າງກັນ.

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

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