Let's Encrypt ແມ່ນສິ້ນສຸດການສະຫນັບສະຫນູນສໍາລັບໂປໂຕຄອນ OCSP ສໍາລັບການກວດສອບໃບຢັ້ງຢືນການຖອນຄືນ

Let's Encrypt, ອົງການໃບຢັ້ງຢືນທີ່ບໍ່ຫວັງຜົນກໍາໄລທີ່ຄວບຄຸມໂດຍຊຸມຊົນແລະໃຫ້ໃບຢັ້ງຢືນໂດຍບໍ່ເສຍຄ່າກັບທຸກໆຄົນ, ໄດ້ຕັດສິນໃຈຢຸດການສະຫນັບສະຫນູນ OCSP (Online Certificate Status Protocol), ທີ່ໃຊ້ໃນການກວດສອບການຖອນໃບຢັ້ງຢືນ. ແທນທີ່ຈະເປັນໂປໂຕຄອນ OCSP, ມັນຖືກສະເໜີໃຫ້ໃຊ້ລາຍການການຖອນໃບຢັ້ງຢືນ (CRL - ລາຍຊື່ການຖອນໃບຢັ້ງຢືນ), ເຜີຍແຜ່ໂດຍບໍລິການເຂົ້າລະຫັດລັບໃຫ້ເລີ່ມໃນປີ 2022. ໃນວັນທີ 7 ພຶດສະພາ 2025, Let's Encrypt ຈະປິດການນຳໃຊ້ການເພີ່ມການອ້າງອີງທີ່ຢູ່ OCSP ໃຫ້ກັບໃບຢັ້ງຢືນທີ່ອອກໃຫ້ ແລະຈະຢຸດການປະມວນຜົນຄຳຮ້ອງຂໍທີ່ກ່ຽວຂ້ອງກັບການໃຊ້ສ່ວນຂະຫຍາຍ "OCSP Must Staple". ໃນວັນທີ 6 ສິງຫາ 2025, ຕົວຈັດການຄຳຮ້ອງຂໍ OCSP ຈະຖືກປິດໃຊ້ງານຢູ່ໃນເຊີບເວີ.

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

ເພື່ອແກ້ໄຂບັນຫາຄວາມເປັນສ່ວນຕົວເມື່ອກວດສອບການຍົກເລີກໃບຢັ້ງຢືນ, ເທັກໂນໂລຢີ OCSP Stapling ໄດ້ຖືກພັດທະນາຂຶ້ນ. ແນວຄວາມຄິດແມ່ນວ່າການຕອບສະໜອງ OCSP ທີ່ຖືກກວດສອບໂດຍໜ່ວຍງານອອກໃບຢັ້ງຢືນສາມາດສົ່ງຕໍ່ໂດຍເຊີບເວີທີ່ໃຫ້ບໍລິການເວັບໄຊທ໌ໃນລະຫວ່າງການເຈລະຈາການເຊື່ອມຕໍ່ TLS ກັບລູກຄ້າ (ການສົ່ງຂໍ້ມູນ OCSP ຖືກໂອນໄປຫາ ເຊີບເວີ ເວັບໄຊທ໌ຕ່າງໆ, ເຊິ່ງລົບລ້າງຄວາມຕ້ອງການໃຫ້ລະບົບລູກຄ້າຕິດຕໍ່ໂດຍກົງກັບເຊີບເວີ OCSP ຂອງໜ່ວຍງານຢັ້ງຢືນ, ໃນຂະນະທີ່ຄວາມຖືກຕ້ອງຂອງການຕອບສະໜອງແມ່ນຮັບປະກັນໂດຍລາຍເຊັນດິຈິຕອນຂອງໜ່ວຍງານຢັ້ງຢືນ).

ນອກເຫນືອຈາກ OCSP Stapling, ມີການເພີ່ມ "OCSP Must Staple" ຕໍ່ໃບຢັ້ງຢືນ, ເຊິ່ງແນະນໍາຕົວທ່ອງເວັບໃຫ້ໃຊ້ເຕັກນິກ OCSP Stapling ແທນທີ່ຈະຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍຂອງ OCSP ໂດຍກົງແລະຮຽກຮ້ອງໃຫ້ໃບຢັ້ງຢືນຖືກຖືວ່າບໍ່ຫນ້າເຊື່ອຖືຖ້າເຄື່ອງແມ່ຂ່າຍທີ່ໃຫ້ບໍລິການເວັບໄຊທ໌ບໍ່. ສົ່ງຄືນການຕອບໂຕ້ OCSP ທີ່ໄດ້ຮັບການຮັບຮອງ. ແຕ່ຫນ້າເສຍດາຍ, ສ່ວນຂະຫຍາຍ "ຕ້ອງ Staple" ບໍ່ໄດ້ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນຕົວທ່ອງເວັບ, ແລະເຕັກໂນໂລຢີ OCSP Stapling ແມ່ນຕິດກັບຄວາມຕ້ອງການທີ່ຈະເປີດໃຊ້ການສະຫນັບສະຫນູນດ້ານ HTTP ຢ່າງຊັດເຈນ (ສະຫນັບສະຫນູນໃນ nginx ນັບຕັ້ງແຕ່ 2013).

ເມື່ອນໍາໃຊ້ CRL, ການກວດສອບການຖອນໃບຢັ້ງຢືນແມ່ນດໍາເນີນຢູ່ໃນລະບົບທ້ອງຖິ່ນໂດຍໃຊ້ລາຍຊື່ທີ່ສ້າງໂດຍເຈົ້າຫນ້າທີ່ການຢັ້ງຢືນ. ຂໍ້ເສຍຂອງວິທີການນີ້ແມ່ນມີຂະຫນາດໃຫຍ່ຫຼາຍຂອງຂໍ້ມູນທີ່ດາວໂຫລດແລະຮູບລັກສະນະຂອງຊ່ອງຫວ່າງເວລາໃນຄວາມກ່ຽວຂ້ອງຂອງຂໍ້ມູນ (ຕົວຢ່າງເຊັ່ນໃນ Firefox, ຂໍ້ມູນຖືກປັບປຸງທຸກໆ 6 ຊົ່ວໂມງ). ບັນຫາກ່ຽວກັບຂະຫນາດໄດ້ຖືກແກ້ໄຂໃນຕົວທ່ອງເວັບໂດຍຜ່ານ CRL proxying ໃນເຄື່ອງແມ່ຂ່າຍຂອງຜູ້ຜະລິດຕົວທ່ອງເວັບ - ຕົວທ່ອງເວັບປະກອບມີ CRL ພື້ນຖານ, ເຊິ່ງໃນລະຫວ່າງການປະຕິບັດງານຈະຖືກ synchronized ເປັນໄລຍະກັບບັນຊີລາຍຊື່ປະຈຸບັນ (ພຽງແຕ່ຂໍ້ມູນການປ່ຽນແປງຖືກໂອນໄປຫາລະບົບຂອງລູກຄ້າ). ເພື່ອຫຼຸດຜ່ອນຂະຫນາດຂອງຖານຂໍ້ມູນ CRL, ໂຄງສ້າງການກັ່ນຕອງ Bloom ທີ່ເປັນໄປໄດ້ແມ່ນຖືກນໍາໃຊ້, ເຊິ່ງອະນຸຍາດໃຫ້ເກັບຮັກສາຖານຂໍ້ມູນ CRL ຄົບຖ້ວນສົມບູນໃນດ້ານລູກຄ້າໃນການເປັນຕົວແທນທີ່ຫນາແຫນ້ນຫຼາຍ. ໃນ Firefox, ເຕັກນິກທີ່ຄ້າຍຄືກັນຖືກປະຕິບັດໂດຍໃຊ້ CRLite toolkit, ແລະໃນ Chrome, CRLSets.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru