Domain fronting ອີງຕາມ TLS 1.3

ການນໍາສະເຫນີ

ລະບົບການກັ່ນຕອງເນື້ອຫາຂອງບໍລິສັດທີ່ທັນສະໄຫມຈາກຜູ້ຜະລິດທີ່ມີຊື່ສຽງເຊັ່ນ Cisco, BlueCoat, FireEye ມີຄວາມຄ້າຍຄືກັນຫຼາຍກັບຄູ່ຮ່ວມງານທີ່ມີອໍານາດຫຼາຍກວ່າຂອງພວກເຂົາ - ລະບົບ DPI, ເຊິ່ງໄດ້ຖືກປະຕິບັດຢ່າງຈິງຈັງໃນລະດັບຊາດ. ໂດຍເນື້ອແທ້ແລ້ວຂອງການເຮັດວຽກຂອງທັງສອງແມ່ນການກວດສອບການຈະລາຈອນທາງອິນເຕີເນັດຂາເຂົ້າແລະຂາອອກແລະ, ອີງຕາມບັນຊີລາຍຊື່ສີດໍາ / ສີຂາວ, ຕັດສິນໃຈຫ້າມການເຊື່ອມຕໍ່ອິນເຕີເນັດ. ແລະເນື່ອງຈາກວ່າທັງສອງຂອງເຂົາເຈົ້າອີງໃສ່ຫຼັກການທີ່ຄ້າຍຄືກັນໃນພື້ນຖານຂອງການເຮັດວຽກຂອງເຂົາເຈົ້າ, ວິທີການສໍາລັບການຫລີກລ່ຽງເຂົາເຈົ້າຈະມີຫຼາຍຄືກັນ.

ຫນຶ່ງໃນເຕັກໂນໂລຢີທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຂ້າມ DPI ແລະລະບົບບໍລິສັດໄດ້ຢ່າງມີປະສິດທິພາບແມ່ນເຕັກໂນໂລຢີດ້ານຫນ້າຂອງໂດເມນ. ໂດຍເນື້ອແທ້ແລ້ວຂອງມັນແມ່ນພວກເຮົາໄປຫາຊັບພະຍາກອນທີ່ຖືກບລັອກ, ເຊື່ອງຢູ່ຫລັງອື່ນ, ໂດເມນສາທາລະນະທີ່ມີຊື່ສຽງທີ່ດີ, ເຊິ່ງແນ່ນອນຈະບໍ່ຖືກບລັອກໂດຍລະບົບໃດກໍ່ຕາມ, ຕົວຢ່າງ google.com.

ຂ້ອນຂ້າງຫຼາຍບົດຄວາມໄດ້ຖືກຂຽນແລ້ວກ່ຽວກັບເຕັກໂນໂລຊີນີ້ແລະຕົວຢ່າງຈໍານວນຫຼາຍໄດ້ຖືກໃຫ້. ຢ່າງໃດກໍ່ຕາມ, ເຕັກໂນໂລຢີ DNS-over-HTTPS ແລະ encrypted-SNI ທີ່ນິຍົມແລະບໍ່ດົນມານີ້ໄດ້ສົນທະນາ, ເຊັ່ນດຽວກັນກັບສະບັບໃຫມ່ຂອງໂປໂຕຄອນ TLS 1.3, ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະພິຈາລະນາທາງເລືອກອື່ນສໍາລັບຫນ້າໂດເມນ.

ຄວາມເຂົ້າໃຈກ່ຽວກັບເຕັກໂນໂລຢີ

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

ຕອນນີ້ໃຫ້ເບິ່ງວິທີການເຮັດວຽກຂອງກົນໄກ eSNI ໃນການປະຕິບັດ.

ໃຫ້ເວົ້າວ່າພວກເຮົາມີຊັບພະຍາກອນອິນເຕີເນັດທີ່ຖືກສະກັດໂດຍການແກ້ໄຂ DPI ທີ່ທັນສະໄຫມ (ໃຫ້ເຮົາ, ຕົວຢ່າງເຊັ່ນ torrent tracker rutracker.nl ທີ່ມີຊື່ສຽງ). ເມື່ອພວກເຮົາພະຍາຍາມເຂົ້າເຖິງເວັບໄຊທ໌ຂອງ torrent tracker, ພວກເຮົາເຫັນມາດຕະຖານຂອງຜູ້ໃຫ້ບໍລິການທີ່ຊີ້ໃຫ້ເຫັນວ່າຊັບພະຍາກອນຖືກບລັອກ:

ຢູ່ໃນເວັບໄຊທ໌ RKN ຕົວຈິງແລ້ວໂດເມນນີ້ແມ່ນຢູ່ໃນລາຍການຢຸດ:

ເມື່ອທ່ານສອບຖາມ whois, ທ່ານສາມາດເບິ່ງວ່າໂດເມນຕົວມັນເອງ "ຖືກເຊື່ອງໄວ້" ຫລັງຜູ້ໃຫ້ບໍລິການຟັງ Cloudflare.

ແຕ່ບໍ່ເຫມືອນກັບ "ຜູ້ຊ່ຽວຊານ" ຈາກ RKN, ພະນັກງານທີ່ມີຄວາມຊໍານິຊໍານານທາງດ້ານເຕັກນິກຈາກ Beeline (ຫຼືສອນໂດຍປະສົບການທີ່ຂົມຂື່ນຂອງຜູ້ຄວບຄຸມທີ່ມີຊື່ສຽງຂອງພວກເຮົາ) ບໍ່ໄດ້ຫ້າມເວັບໄຊທ໌ໂດຍທີ່ຢູ່ IP ຢ່າງໂງ່, ແຕ່ໄດ້ເພີ່ມຊື່ໂດເມນໃນບັນຊີລາຍຊື່ຢຸດ. ທ່ານສາມາດກວດສອບນີ້ໄດ້ຢ່າງງ່າຍດາຍຖ້າທ່ານເບິ່ງສິ່ງທີ່ໂດເມນອື່ນຖືກເຊື່ອງໄວ້ຢູ່ເບື້ອງຫຼັງທີ່ຢູ່ IP ດຽວກັນ, ໄປຢ້ຽມຢາມຫນຶ່ງຂອງພວກເຂົາແລະເຫັນວ່າການເຂົ້າເຖິງບໍ່ໄດ້ຖືກບລັອກ:

ນີ້ເກີດຂຶ້ນແນວໃດ? DPI ຂອງຜູ້ໃຫ້ບໍລິການຮູ້ໄດ້ແນວໃດວ່າໂດເມນຂອງຂ້ອຍເປີດຢູ່, ນັບຕັ້ງແຕ່ການສື່ສານທັງຫມົດເກີດຂື້ນຜ່ານໂປໂຕຄອນ https, ແລະພວກເຮົາຍັງບໍ່ໄດ້ສັງເກດເຫັນການທົດແທນໃບຢັ້ງຢືນ https ຈາກ Beeline? ລາວເປັນ clairvoyant ຫຼືຂ້ອຍຖືກຕິດຕາມ?

ໃຫ້ພະຍາຍາມຕອບຄໍາຖາມນີ້ໂດຍການເບິ່ງການຈະລາຈອນຜ່ານ wireshark

ພາບຫນ້າຈໍສະແດງໃຫ້ເຫັນວ່າທໍາອິດຕົວທ່ອງເວັບໄດ້ຮັບທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍຜ່ານ DNS, ຫຼັງຈາກນັ້ນການຈັບມື TCP ມາດຕະຖານເກີດຂື້ນກັບເຄື່ອງແມ່ຂ່າຍປາຍທາງ, ແລະຫຼັງຈາກນັ້ນຕົວທ່ອງເວັບພະຍາຍາມສ້າງການເຊື່ອມຕໍ່ SSL ກັບເຄື່ອງແມ່ຂ່າຍ. ເພື່ອເຮັດສິ່ງນີ້, ມັນສົ່ງຊຸດ SSL Client Hello, ເຊິ່ງປະກອບດ້ວຍຊື່ຂອງໂດເມນແຫຼ່ງໃນຂໍ້ຄວາມທີ່ຊັດເຈນ. ຊ່ອງຂໍ້ມູນນີ້ແມ່ນຕ້ອງການໂດຍເຊີບເວີ cloudflare frontend ເພື່ອເຮັດໃຫ້ເສັ້ນທາງເຊື່ອມຕໍ່ຢ່າງຖືກຕ້ອງ. ນີ້ແມ່ນບ່ອນທີ່ຜູ້ໃຫ້ບໍລິການ DPI ຈັບພວກເຮົາ, ທໍາລາຍການເຊື່ອມຕໍ່ຂອງພວກເຮົາ. ໃນເວລາດຽວກັນ, ພວກເຮົາບໍ່ໄດ້ຮັບ stub ຈາກຜູ້ໃຫ້ບໍລິການ, ແລະພວກເຮົາເຫັນຂໍ້ຜິດພາດຂອງຕົວທ່ອງເວັບມາດຕະຖານຄືກັບວ່າເວັບໄຊທ໌ຖືກປິດຫຼືພຽງແຕ່ບໍ່ເຮັດວຽກ:

ຕອນນີ້ໃຫ້ເປີດໃຊ້ກົນໄກ eSNI ໃນຕົວທ່ອງເວັບ, ດັ່ງທີ່ຂຽນໄວ້ໃນຄໍາແນະນໍາສໍາລັບ Firefox :
ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາເປີດຫນ້າການຕັ້ງຄ່າ Firefox about: config ແລະເປີດໃຊ້ການຕັ້ງຄ່າຕໍ່ໄປນີ້:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

ຫຼັງຈາກນີ້, ພວກເຮົາຈະກວດເບິ່ງວ່າການຕັ້ງຄ່າເຮັດວຽກຢ່າງຖືກຕ້ອງຢູ່ໃນເວັບໄຊທ໌ cloudflare. ການເຊື່ອມຕໍ່ ແລະໃຫ້ລອງໃຊ້ trick ກັບຕົວຕິດຕາມ torrent ຂອງພວກເຮົາອີກຄັ້ງ.

Voila. ບົບຕິດຕາມລຸດ favorite ຂອງພວກເຮົາເປີດໂດຍບໍ່ມີ VPN ຫຼືເຄື່ອງແມ່ຂ່າຍຕົວແທນໃດໆ. ຕອນນີ້ໃຫ້ເບິ່ງທີ່ຂີ້ເຫຍື້ອການຈະລາຈອນໃນ wireshark ເພື່ອເບິ່ງວ່າເກີດຫຍັງຂຶ້ນ.

ເວລານີ້, ຊຸດສະບາຍດີລູກຄ້າ ssl ບໍ່ມີໂດເມນປາຍທາງຢ່າງຊັດເຈນ, ແຕ່, ພາກສະຫນາມໃຫມ່ປາກົດຢູ່ໃນຊຸດ - encrypted_server_name - ນີ້ແມ່ນບ່ອນທີ່ມີຄ່າຂອງ rutracker.nl, ແລະພຽງແຕ່ເຄື່ອງແມ່ຂ່າຍຫນ້າ cloudflare ເທົ່ານັ້ນທີ່ສາມາດຖອດລະຫັດນີ້ໄດ້. ພາກສະຫນາມ. ແລະຖ້າເປັນດັ່ງນັ້ນ, ຜູ້ໃຫ້ບໍລິການ DPI ບໍ່ມີທາງເລືອກນອກເຫນືອຈາກການລ້າງມືແລະອະນຸຍາດໃຫ້ການຈະລາຈອນດັ່ງກ່າວ. ບໍ່ມີທາງເລືອກອື່ນທີ່ມີການເຂົ້າລະຫັດ.

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

Domain fronting ກັບ eSNI

ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າ curl ໃຊ້ຫ້ອງສະຫມຸດ openssl ມາດຕະຖານເພື່ອເຊື່ອມຕໍ່ຜ່ານໂປໂຕຄອນ https, ກ່ອນອື່ນຫມົດພວກເຮົາຈໍາເປັນຕ້ອງສະຫນອງການສະຫນັບສະຫນູນ eSNI ຢູ່ທີ່ນັ້ນ. ບໍ່ມີການສະຫນັບສະຫນູນ eSNI ໃນສາຂາ openssl master ເທື່ອ, ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ດາວໂຫລດສາຂາ openssl ພິເສດ, ລວບລວມແລະຕິດຕັ້ງມັນ.

ພວກເຮົາ clone repository ຈາກ GitHub ແລະລວບລວມຕາມປົກກະຕິ:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

ຕໍ່ໄປ, ພວກເຮົາ clone repository ດ້ວຍ curl ແລະ configure ການລວບລວມຂອງມັນໂດຍໃຊ້ຫ້ອງສະຫມຸດ openssl ຂອງພວກເຮົາທີ່ລວບລວມ:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

ໃນທີ່ນີ້ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະລະບຸໄດເລກະທໍລີທັງຫມົດທີ່ openssl ຢ່າງຖືກຕ້ອງ (ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນ /opt/openssl/) ແລະໃຫ້ແນ່ໃຈວ່າຂະບວນການຕັ້ງຄ່າຜ່ານໄປໂດຍບໍ່ມີຂໍ້ຜິດພາດ.

ຖ້າການຕັ້ງຄ່າປະສົບຜົນສໍາເລັດ, ພວກເຮົາຈະເຫັນເສັ້ນ:

ຄຳເຕືອນ: esni ESNI ເປີດໃຊ້ງານແລ້ວ ແຕ່ໝາຍເຖິງການທົດລອງ. ໃຊ້ດ້ວຍຄວາມລະມັດລະວັງ!

$ make

ຫຼັງຈາກສ້າງຊຸດສໍາເລັດແລ້ວ, ພວກເຮົາຈະໃຊ້ໄຟລ໌ bash ພິເສດຈາກ openssl ເພື່ອກໍານົດແລະດໍາເນີນການ curl. ໃຫ້ພວກເຮົາຄັດລອກໄປທີ່ໄດເລກະທໍລີດ້ວຍ curl ເພື່ອຄວາມສະດວກ:

cp /opt/openssl/esnistuff/curl-esni 

ແລະເຮັດການຮ້ອງຂໍການທົດສອບ https ກັບເຄື່ອງແມ່ຂ່າຍ cloudflare, ໃນຂະນະທີ່ບັນທຶກ DNS ແລະ TLS packets ໃນເວລາດຽວກັນໃນ Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

ໃນການຕອບສະຫນອງຂອງເຊີຟເວີ, ນອກເຫນືອຈາກຂໍ້ມູນການດີບັກຈໍານວນຫລາຍຈາກ openssl ແລະ curl, ພວກເຮົາຈະໄດ້ຮັບການຕອບສະຫນອງ HTTP ກັບລະຫັດ 301 ຈາກ cloudflare.

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

ເຊິ່ງຊີ້ບອກວ່າການຮ້ອງຂໍຂອງພວກເຮົາໄດ້ຖືກຈັດສົ່ງຢ່າງສໍາເລັດຜົນກັບເຄື່ອງແມ່ຂ່າຍປາຍທາງ, ໄດ້ຍິນແລະດໍາເນີນການ.

ຕອນນີ້ໃຫ້ເບິ່ງ dump ການຈະລາຈອນໃນ wireshark, i.e. ສິ່ງທີ່ຜູ້ໃຫ້ບໍລິການ DPI ເຫັນໃນກໍລະນີນີ້.

ມັນສາມາດເຫັນໄດ້ວ່າ curl ທໍາອິດຫັນໄປຫາເຄື່ອງແມ່ຂ່າຍ DNS ສໍາລັບລະຫັດ eSNI ສາທາລະນະສໍາລັບເຄື່ອງແມ່ຂ່າຍ cloudflare - ການຮ້ອງຂໍ DNS TXT ກັບ _esni.cloudflare.com (ຊຸດທີ 13). ຫຼັງຈາກນັ້ນ, ການນໍາໃຊ້ຫ້ອງສະຫມຸດ openssl, curl ສົ່ງຄໍາຮ້ອງຂໍ TLS 1.3 ໄປຫາເຄື່ອງແມ່ຂ່າຍ cloudflare ທີ່ພາກສະຫນາມ SNI ຖືກເຂົ້າລະຫັດດ້ວຍລະຫັດສາທາລະນະທີ່ໄດ້ຮັບໃນຂັ້ນຕອນກ່ອນຫນ້າ (packet #22). ແຕ່, ນອກເຫນືອໄປຈາກພາກສະຫນາມ eSNI, ຊຸດ SSL-hello ຍັງປະກອບມີພາກສະຫນາມທີ່ມີປົກກະຕິ - ເປີດ SNI, ເຊິ່ງພວກເຮົາສາມາດກໍານົດໃນຄໍາສັ່ງໃດໆ (ໃນກໍລະນີນີ້ - www.hello-rkn.ru).

ຊ່ອງຂໍ້ມູນ SNI ທີ່ເປີດນີ້ບໍ່ໄດ້ຖືກພິຈາລະນາໃນທາງໃດກໍ່ຕາມເມື່ອປະມວນຜົນໂດຍເຄື່ອງແມ່ຂ່າຍ cloudflare ແລະພຽງແຕ່ເຮັດຫນ້າທີ່ເປັນຫນ້າກາກສໍາລັບຜູ້ໃຫ້ບໍລິການ DPI. ເຄື່ອງແມ່ຂ່າຍ cloudflare ໄດ້ຮັບແພັກເກັດ ssl-hello ຂອງພວກເຮົາ, ຖອດລະຫັດ eSNI, ສະກັດ SNI ຕົ້ນສະບັບຈາກບ່ອນນັ້ນແລະປຸງແຕ່ງມັນຄືກັບວ່າບໍ່ມີຫຍັງເກີດຂຶ້ນ (ມັນເຮັດທຸກຢ່າງຕາມແຜນການໃນເວລາທີ່ພັດທະນາ eSNI).

ສິ່ງດຽວທີ່ສາມາດຈັບໄດ້ໃນກໍລະນີນີ້ຈາກມຸມເບິ່ງ DPI ແມ່ນການຮ້ອງຂໍ DNS ຕົ້ນຕໍກັບ _esni.cloudflare.com. ແຕ່ພວກເຮົາເຮັດໃຫ້ການຮ້ອງຂໍ DNS ເປີດພຽງແຕ່ເພື່ອສະແດງໃຫ້ເຫັນວ່າກົນໄກນີ້ເຮັດວຽກຈາກພາຍໃນ.

ເພື່ອສຸດທ້າຍດຶງຜ້າພົມອອກຈາກພາຍໃຕ້ DPI, ພວກເຮົາໃຊ້ກົນໄກ DNS-over-HTTPS ທີ່ໄດ້ກ່າວມາແລ້ວ. ຄໍາອະທິບາຍເລັກນ້ອຍ - DOH ແມ່ນໂປໂຕຄອນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປ້ອງກັນການໂຈມຕີຂອງຜູ້ຊາຍໃນກາງໂດຍການສົ່ງຄໍາຮ້ອງຂໍ DNS ຜ່ານ HTTPS.

ໃຫ້ດໍາເນີນການຮ້ອງຂໍອີກເທື່ອຫນຶ່ງ, ແຕ່ເວລານີ້ພວກເຮົາຈະໄດ້ຮັບກະແຈ eSNI ສາທາລະນະຜ່ານ https protocol, ບໍ່ແມ່ນ DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

ການຖິ້ມຂີ້ເຫຍື້ອການຮ້ອງຂໍແມ່ນສະແດງຢູ່ໃນຮູບຫນ້າຈໍຂ້າງລຸ່ມນີ້:

ມັນສາມາດເຫັນໄດ້ວ່າ curl ທໍາອິດເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍຂອງ mozilla.cloudflare-dns.com ຜ່ານ DoH protocol (ການເຊື່ອມຕໍ່ https ກັບເຄື່ອງແມ່ຂ່າຍ 104.16.249.249) ເພື່ອໃຫ້ໄດ້ຮັບຈາກພວກເຂົາມູນຄ່າຂອງກະແຈສາທາລະນະສໍາລັບການເຂົ້າລະຫັດ SNI, ແລະຫຼັງຈາກນັ້ນໄປປາຍທາງ. server, ເຊື່ອງຢູ່ຫລັງໂດເມນ www.hello-rkn.ru.

ນອກເຫນືອຈາກຕົວແກ້ໄຂ DoH ຂ້າງເທິງ mozilla.cloudflare-dns.com, ພວກເຮົາສາມາດໃຊ້ບໍລິການ DoH ທີ່ນິຍົມອື່ນໆ, ສໍາລັບການຍົກຕົວຢ່າງ, ຈາກບໍລິສັດຊົ່ວຮ້າຍທີ່ມີຊື່ສຽງ.
ໃຫ້ດໍາເນີນການສອບຖາມຕໍ່ໄປນີ້:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

ແລະພວກເຮົາໄດ້ຮັບຄໍາຕອບ:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

ໃນກໍລະນີນີ້, ພວກເຮົາໄດ້ຫັນໄປຫາເຄື່ອງແມ່ຂ່າຍ rutracker.nl ທີ່ຖືກບລັອກ, ໂດຍໃຊ້ DoH solver dns.google (ບໍ່ມີ typo ຢູ່ທີ່ນີ້, ໃນປັດຈຸບັນບໍລິສັດທີ່ມີຊື່ສຽງມີໂດເມນລະດັບທໍາອິດຂອງຕົນເອງ) ແລະກວມເອົາຕົວເຮົາເອງກັບໂດເມນອື່ນ, ທີ່ເຄັ່ງຄັດ. ຫ້າມສໍາລັບ DPIs ທັງຫມົດເພື່ອສະກັດພາຍໃຕ້ຄວາມເຈັບປວດຂອງການເສຍຊີວິດ. ອີງຕາມຄໍາຕອບທີ່ໄດ້ຮັບ, ທ່ານສາມາດເຂົ້າໃຈວ່າຄໍາຮ້ອງຂໍຂອງພວກເຮົາໄດ້ຖືກດໍາເນີນຢ່າງສໍາເລັດຜົນ.

ໃນຖານະເປັນການກວດສອບເພີ່ມເຕີມວ່າ DPI ຂອງຜູ້ໃຫ້ບໍລິການຕອບສະຫນອງກັບ SNI ທີ່ເປີດ, ທີ່ພວກເຮົາສົ່ງເປັນການປົກຫຸ້ມຂອງ, ພວກເຮົາສາມາດເຮັດການຮ້ອງຂໍກັບ rutracker.nl ພາຍໃຕ້ການອ້າງອິງຂອງຊັບພະຍາກອນທີ່ຕ້ອງຫ້າມອື່ນໆ, ຕົວຢ່າງ, ຕົວຕິດຕາມ torrent "ດີ" ອື່ນ:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

ພວກເຮົາຈະບໍ່ໄດ້ຮັບການຕອບຮັບຈາກເຄື່ອງແມ່ຂ່າຍ, ເນື່ອງຈາກວ່າ ... ການຮ້ອງຂໍຂອງພວກເຮົາຈະຖືກສະກັດໂດຍລະບົບ DPI.

ການສະຫລຸບສັ້ນຂອງພາກທໍາອິດ

ດັ່ງນັ້ນ, ພວກເຮົາສາມາດສະແດງໃຫ້ເຫັນເຖິງການເຮັດວຽກຂອງ eSNI ໂດຍໃຊ້ openssl ແລະ curl ແລະທົດສອບການເຮັດວຽກຂອງຫນ້າໂດເມນໂດຍອີງໃສ່ eSNI. ໃນທາງດຽວກັນ, ພວກເຮົາສາມາດດັດແປງເຄື່ອງມືທີ່ພວກເຮົາມັກທີ່ໃຊ້ຫ້ອງສະຫມຸດ openssl ເພື່ອເຮັດວຽກ "ພາຍໃຕ້ການປອມແປງ" ຂອງໂດເມນອື່ນໆ. ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນບົດຄວາມຕໍ່ໄປຂອງພວກເຮົາ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com