Firefox ແລະ Cloudflare ເປີດໃຊ້ການສະຫນັບສະຫນູນ ECH ສໍາລັບການເຊື່ອງໂດເມນຢູ່ໃນການຈະລາຈອນ HTTPS

Mozilla ໄດ້ປະກາດການລວມເອົາການສະຫນັບສະຫນູນຜູ້ໃຊ້ຂອງສາຂາທີ່ຫມັ້ນຄົງຂອງ Firefox ສໍາລັບກົນໄກ ECH (Encrypted Client Hello), ເຊິ່ງສືບຕໍ່ການພັດທະນາເຕັກໂນໂລຢີ ESNI (Encrypted Server Name Indication) ແລະຖືກອອກແບບມາເພື່ອເຂົ້າລະຫັດຂໍ້ມູນກ່ຽວກັບພາລາມິເຕີຂອງ TLS sessions. , ເຊັ່ນຊື່ໂດເມນທີ່ຮ້ອງຂໍ. ລະຫັດສໍາລັບການເຮັດວຽກກັບ ECH ໃນເບື້ອງຕົ້ນໄດ້ຖືກເພີ່ມເຂົ້າໃນການປ່ອຍ Firefox 85, ແຕ່ຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ. Chrome ຄ່ອຍໆເລີ່ມປະກອບການຮອງຮັບ ECH ເລີ່ມຕົ້ນດ້ວຍການເປີດຕົວ Chrome 115.

ເນື່ອງຈາກວ່ານອກເໜືອໄປຈາກການເຊື່ອມຕໍ່ກັບ ເຊີບເວີ ຂໍ້ມູນໂດເມນທີ່ຮ້ອງຂໍນັ້ນຮົ່ວໄຫຼຜ່ານ DNS. ເພື່ອການປົກປ້ອງຢ່າງເຕັມທີ່, ນອກເໜືອໄປຈາກ ECH, ທ່ານຕ້ອງໃຊ້ DNS ຜ່ານ HTTPS ຫຼື DNS ຜ່ານ TLS ເພື່ອເຂົ້າລະຫັດການຈະລາຈອນ DNS. Firefox ຈະບໍ່ໃຊ້ ECH ໂດຍບໍ່ເປີດໃຊ້ DNS ຜ່ານ HTTPS ໃນການຕັ້ງຄ່າ. ​​ທ່ານສາມາດກວດສອບການສະໜັບສະໜູນ ECH ໃນໂປຣແກຣມທ່ອງເວັບຂອງທ່ານໃນໜ້ານີ້.

ຫນຶ່ງໃນປັດໃຈທີ່ເຮັດໃຫ້ການສະຫນັບສະຫນູນ ECH ໂດຍຄ່າເລີ່ມຕົ້ນໃນ Firefox ແມ່ນການລວມເອົາການສະຫນັບສະຫນູນ ECH ຂອງ Cloudflare ໃນເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາຂອງມັນສອງສາມມື້ກ່ອນຫນ້ານີ້. ໃນດ້ານປະຕິບັດ, ເນື່ອງຈາກວ່າຂໍ້ມູນກ່ຽວກັບໂຮດທີ່ຮ້ອງຂໍໃນເວລານໍາໃຊ້ ECH ແມ່ນຖືກເຊື່ອງໄວ້ຈາກການວິເຄາະ, ການກັ່ນຕອງແລະສະກັດເວັບໄຊທ໌ທີ່ບໍ່ຕ້ອງການໂດຍໃຊ້ Cloudflare CDN ໃນປັດຈຸບັນຈະຕ້ອງປິດເຄືອຂ່າຍ Cloudflare ທັງຫມົດ, ຂັດຂວາງການຮ້ອງຂໍທັງຫມົດຈາກ ECH, ຫຼືຈັດຕັ້ງການຂັດຂວາງ HTTPS ໂດຍໃຊ້ໃບຢັ້ງຢືນຮາກປອມ. ໃນ​ລະ​ບົບ​ຜູ້​ໃຊ້​.

ໃນເບື້ອງຕົ້ນ, ເພື່ອຈັດລະບຽບການເຮັດວຽກຢູ່ໃນຫນຶ່ງທີ່ຢູ່ IP ຂອງເວັບໄຊທ໌ HTTPS ຫຼາຍ, ນາມສະກຸນ TLS SNI ໄດ້ຖືກນໍາໃຊ້, ເຊິ່ງຊື່ຂອງເຈົ້າພາບທີ່ຮ້ອງຂໍໄດ້ຖືກລະບຸໄວ້ໃນຂໍ້ຄວາມ ClientHello ທີ່ສົ່ງກ່ອນທີ່ຈະສ້າງຊ່ອງທາງການສື່ສານທີ່ຖືກເຂົ້າລະຫັດ. ຄຸນນະສົມບັດນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະແຈກຢາຍການຮ້ອງຂໍໃນທົ່ວ virtual hosts ໃນຂັ້ນຕອນທໍາອິດຂອງຂະບວນການເຊື່ອມຕໍ່, ແຕ່ຍັງເຮັດໃຫ້ມັນເປັນໄປໄດ້ໃນດ້ານ ISP ເພື່ອຄັດເລືອກເອົາການເຂົ້າຊົມ HTTPS ແລະວິເຄາະເວັບໄຊທ໌ທີ່ຜູ້ໃຊ້ເປີດ, ເຊິ່ງບໍ່ອະນຸຍາດໃຫ້ບັນລຸຄວາມລັບຢ່າງສົມບູນໃນເວລານໍາໃຊ້. HTTPS.

ເພື່ອແກ້ໄຂບັນຫານີ້ແລະປ້ອງກັນການຮົ່ວໄຫລຂອງຂໍ້ມູນກ່ຽວກັບເວັບໄຊທ໌ທີ່ຮ້ອງຂໍ, ການຂະຫຍາຍ ESNI ໄດ້ຖືກສະເຫນີຕໍ່ມາທີ່ປະຕິບັດການເຂົ້າລະຫັດຂໍ້ມູນດ້ວຍຊື່ໂຮດ. ໃນລະຫວ່າງການປະຕິບັດ ESNI, ມັນໄດ້ຖືກເປີດເຜີຍວ່າກົນໄກທີ່ສະເຫນີບໍ່ໄດ້ກວມເອົາແຫຼ່ງທີ່ເປັນໄປໄດ້ທັງຫມົດຂອງການຮົ່ວໄຫລຂອງຂໍ້ມູນຂອງເຈົ້າພາບແລະການນໍາໃຊ້ຂອງມັນບໍ່ພຽງພໍເພື່ອຮັບປະກັນຄວາມລັບຢ່າງສົມບູນຂອງກອງປະຊຸມ HTTPS. ໂດຍສະເພາະ, ໃນເວລາທີ່ສືບຕໍ່ກອງປະຊຸມທີ່ສ້າງຕັ້ງຂຶ້ນກ່ອນຫນ້ານີ້, ຊື່ໂດເມນໃນຂໍ້ຄວາມທີ່ຊັດເຈນໄດ້ສືບຕໍ່ຖືກລະບຸໄວ້ໃນຕົວກໍານົດການຂອງການຂະຫຍາຍ PSK (Pre-Shared Key) TLS. ນອກຈາກນັ້ນ, ຄວາມພະຍາຍາມໃນການປະຕິບັດ ESNI ໄດ້ກໍານົດຄວາມເຂົ້າກັນໄດ້ແລະການຂະຫຍາຍບັນຫາທີ່ຂັດຂວາງການຮັບຮອງເອົາ ESNI ຢ່າງກວ້າງຂວາງ.

ການພິຈາລະນາຂໍ້ບົກຜ່ອງທີ່ລະບຸໄວ້ຂອງ ESNI, ກົນໄກ ECH ສາກົນໃຫມ່ໄດ້ຖືກພັດທະນາທີ່ອະນຸຍາດໃຫ້ເຂົ້າລະຫັດຕົວກໍານົດການຂອງສ່ວນຂະຫຍາຍ TLS ໃດໆ. ໃນທາງດ້ານວິຊາການ, ຄວາມແຕກຕ່າງຕົ້ນຕໍລະຫວ່າງ ECH ແລະ ESNI ແມ່ນວ່າແທນທີ່ຈະເປັນແຕ່ລະຂົງເຂດ, ຂໍ້ຄວາມ ClientHello ທັງຫມົດຈະຖືກເຂົ້າລະຫັດໃນເວລາດຽວກັນ. ECH ກ່ຽວຂ້ອງກັບການແຍກ ClientHello ອອກເປັນສອງຂໍ້ຄວາມແຍກຕ່າງຫາກ - ຂໍ້ຄວາມ ClientHelloInner ທີ່ເຂົ້າລະຫັດໄວ້ (SNI Inner) ແລະຂໍ້ຄວາມ ClientHelloOuter ທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ (SNI Outer). SNI Outer ທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດລັບມີຂໍ້ມູນທີ່ບໍ່ແມ່ນຄວາມເປັນສ່ວນຕົວເຊັ່ນ: ສະບັບ TLS ແລະບັນຊີລາຍຊື່ຂອງລະຫັດລັບທີ່ໃຊ້, ເຊັ່ນດຽວກັນກັບຊື່ໂດເມນທົ່ວໄປທີ່ບໍ່ຊ້ໍາກັນກັບຊື່ທີ່ແທ້ຈິງຂອງໂດເມນທີ່ຮ້ອງຂໍ. ຕົວຢ່າງ, ສໍາລັບລູກຄ້າ Cloudflare ທັງຫມົດ, SNI Outer ທີ່ບໍ່ເຂົ້າລະຫັດໄດ້ກໍານົດໂຮດທົ່ວໄປ "cloudflare-ech.com", ແຕ່ຊື່ທີ່ແທ້ຈິງຂອງໂຮດທີ່ຮ້ອງຂໍແມ່ນຖືກສົ່ງໄປຢູ່ໃນ SNI Inner ທີ່ເຂົ້າລະຫັດແລະບໍ່ສາມາດໃຊ້ໄດ້ສໍາລັບການວິເຄາະ.

ECH ຍັງໃຊ້ຮູບແບບການແຈກຢາຍລະຫັດລັບທີ່ແຕກຕ່າງກັນ: ຂໍ້ມູນລະຫັດສາທາລະນະຖືກສົ່ງຜ່ານບັນທຶກ DNS HTTPSSVC ແທນທີ່ຈະເປັນບັນທຶກ TXT. ການເຂົ້າລະຫັດແບບຕົ້ນທາງຫາປາຍທາງທີ່ໄດ້ຮັບການພິສູດຢືນຢັນໂດຍອີງໃສ່ກົນໄກ HPKE (Hybrid Public Key Encryption) ແມ່ນໃຊ້ເພື່ອຮັບ ແລະ ເຂົ້າລະຫັດລະຫັດ. ECH ຍັງຮອງຮັບການສົ່ງລະຫັດລັບທີ່ປອດໄພຈາກເຊີບເວີ, ເຊິ່ງສາມາດໃຊ້ໄດ້ໃນກໍລະນີທີ່ມີການໝູນວຽນລະຫັດ. ເຄື່ອງແມ່ຂ່າຍ ແລະ ເພື່ອແກ້ໄຂບັນຫາກ່ຽວກັບການດຶງເອົາກະແຈທີ່ລ້າສະໄໝຈາກແຄດ DNS.

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