ວິທີການປົກປ້ອງເວັບໄຊທ໌ສາທາລະນະຂອງທ່ານດ້ວຍ ESNI

ສະບາຍດີ Habr, ຂ້ອຍຊື່ Ilya, ຂ້ອຍເຮັດວຽກຢູ່ໃນທີມງານເວທີທີ່ Exness. ພວກເຮົາພັດທະນາແລະປະຕິບັດອົງປະກອບພື້ນຖານໂຄງລ່າງຫຼັກທີ່ທີມງານພັດທະນາຜະລິດຕະພັນຂອງພວກເຮົາໃຊ້.

ໃນບົດຄວາມນີ້, ຂ້ອຍຢາກແບ່ງປັນປະສົບການຂອງຂ້ອຍໃນການປະຕິບັດເຕັກໂນໂລຢີ SNI (ESNI) ທີ່ຖືກເຂົ້າລະຫັດໃນໂຄງສ້າງພື້ນຖານຂອງເວັບໄຊທ໌ສາທາລະນະ.

ການນໍາໃຊ້ເຕັກໂນໂລຢີນີ້ຈະເພີ່ມລະດັບຄວາມປອດໄພໃນເວລາທີ່ເຮັດວຽກກັບເວັບໄຊທ໌ສາທາລະນະແລະປະຕິບັດຕາມມາດຕະຖານຄວາມປອດໄພພາຍໃນທີ່ບໍລິສັດໄດ້ຮັບຮອງເອົາ.

ກ່ອນອື່ນ ໝົດ, ຂ້ອຍຢາກຊີ້ໃຫ້ເຫັນວ່າເຕັກໂນໂລຢີບໍ່ໄດ້ມາດຕະຖານແລະຍັງຢູ່ໃນຮ່າງ, ແຕ່ CloudFlare ແລະ Mozilla ສະຫນັບສະຫນູນມັນແລ້ວ (ໃນ ຮ່າງ01). ນີ້ກະຕຸ້ນພວກເຮົາສໍາລັບການທົດລອງດັ່ງກ່າວ.

ບິດຂອງທິດສະດີ

ESNI ເປັນສ່ວນຂະຫຍາຍຂອງໂປໂຕຄອນ TLS 1.3 ທີ່ອະນຸຍາດໃຫ້ເຂົ້າລະຫັດ SNI ໃນຂໍ້ຄວາມ "ສະບາຍດີລູກຄ້າ" TLS handshake. ນີ້ແມ່ນສິ່ງທີ່ Client Hello ເບິ່ງຄືວ່າມີການສະຫນັບສະຫນູນ ESNI (ແທນທີ່ຈະເປັນ SNI ປົກກະຕິທີ່ພວກເຮົາເຫັນ ESNI):

 ເພື່ອໃຊ້ ESNI, ທ່ານຕ້ອງການສາມອົງປະກອບ:

• DNS; 
• ສະຫນັບສະຫນູນລູກຄ້າ;
• ສະຫນັບສະຫນູນດ້ານເຄື່ອງແມ່ຂ່າຍ.

DNS

ທ່ານຈໍາເປັນຕ້ອງເພີ່ມສອງບັນທຶກ DNS - Aແລະ TXT (ບັນທຶກ TXT ມີລະຫັດສາທາລະນະທີ່ລູກຄ້າສາມາດເຂົ້າລະຫັດ SNI) - ເບິ່ງຂ້າງລຸ່ມນີ້. ນອກຈາກນັ້ນ, ຕ້ອງມີການສະຫນັບສະຫນູນ DoH (DNS ຜ່ານ HTTPS) ເພາະວ່າລູກຄ້າທີ່ມີຢູ່ (ເບິ່ງຂ້າງລຸ່ມນີ້) ບໍ່ເປີດໃຊ້ການສະຫນັບສະຫນູນ ESNI ໂດຍບໍ່ມີ DoH. ນີ້ແມ່ນເຫດຜົນ, ເພາະວ່າ ESNI ຫມາຍເຖິງການເຂົ້າລະຫັດຊື່ຂອງຊັບພະຍາກອນທີ່ພວກເຮົາກໍາລັງເຂົ້າເຖິງ, ນັ້ນແມ່ນ, ມັນບໍ່ມີຄວາມຫມາຍທີ່ຈະເຂົ້າເຖິງ DNS ຜ່ານ UDP. ຍິ່ງໄປກວ່ານັ້ນ, ການນໍາໃຊ້ DNSSEC ອະນຸຍາດໃຫ້ທ່ານເພື່ອປ້ອງກັນການໂຈມຕີ cache ເປັນພິດໃນສະຖານະການນີ້.

ປະຈຸບັນມີຢູ່ ຜູ້ໃຫ້ບໍລິການ DoH ຫຼາຍໆຄົນ, ໃນບັນດາພວກເຂົາ:

• CloudFlare
• OpenDNS
• ກູໂກ

CloudFlare ປະກາດ (ກວດເບິ່ງຕົວທ່ອງເວັບຂອງຂ້ອຍ → SNI ທີ່ເຂົ້າລະຫັດ → ຮຽນຮູ້ເພີ່ມເຕີມ) ວ່າເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາສະຫນັບສະຫນູນ ESNI ແລ້ວ, ນັ້ນແມ່ນ, ສໍາລັບເຄື່ອງແມ່ຂ່າຍ CloudFlare ໃນ DNS ພວກເຮົາມີຢ່າງຫນ້ອຍສອງບັນທຶກ - A ແລະ TXT. ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້ພວກເຮົາສອບຖາມ Google DNS (ຜ່ານ HTTPS): 

А ເຂົ້າ:

curl 'https://dns.google.com/resolve?name=www.cloudflare.com&type=A' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "www.cloudflare.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.210.9"
    },
    {
      "name": "www.cloudflare.com.",
      "type": 1,
      "TTL": 257,
      "data": "104.17.209.9"
    }
  ]
}

TXT ບັນທຶກ, ການຮ້ອງຂໍແມ່ນສ້າງຂື້ນຕາມແມ່ແບບ _esni.FQDN:

curl 'https://dns.google.com/resolve?name=_esni.www.cloudflare.com&type=TXT' 
-s -H 'accept: application/dns+json'
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16
    }
  ],
  "Answer": [
    {
    "name": "_esni.www.cloudflare.com.",
    "type": 16,
    "TTL": 1799,
    "data": ""/wEUgUKlACQAHQAg9SiAYQ9aUseUZr47HYHvF5jkt3aZ5802eAMJPhRz1QgAAhMBAQQAAAAAXtUmAAAAAABe3Q8AAAA=""
    }
  ],
  "Comment": "Response from 2400:cb00:2049:1::a29f:209."
}

ດັ່ງນັ້ນ, ຈາກທັດສະນະ DNS, ພວກເຮົາຄວນໃຊ້ DoH (ມັກກັບ DNSSEC) ແລະເພີ່ມສອງລາຍການ. 

ການຊ່ວຍເຫຼືອລູກຄ້າ

ຖ້າພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບຕົວທ່ອງເວັບ, ຫຼັງຈາກນັ້ນໃນເວລານີ້ ການສະຫນັບສະຫນູນແມ່ນປະຕິບັດໃນ FireFox ເທົ່ານັ້ນ. ມັນເປັນ ນີ້ແມ່ນຄໍາແນະນໍາກ່ຽວກັບວິທີການເປີດໃຊ້ການສະຫນັບສະຫນູນ ESNI ແລະ DoH ໃນ FireFox. ຫຼັງຈາກທີ່ຕົວທ່ອງເວັບຖືກຕັ້ງຄ່າ, ພວກເຮົາຄວນຈະເຫັນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

ການເຊື່ອມຕໍ່ ເພື່ອກວດເບິ່ງຕົວທ່ອງເວັບ.

ແນ່ນອນ, TLS 1.3 ຕ້ອງຖືກນໍາໃຊ້ເພື່ອສະຫນັບສະຫນູນ ESNI, ເນື່ອງຈາກວ່າ ESNI ແມ່ນການຂະຫຍາຍໄປຫາ TLS 1.3.

ສໍາລັບຈຸດປະສົງຂອງການທົດສອບ backend ກັບສະຫນັບສະຫນູນ ESNI, ພວກເຮົາໄດ້ປະຕິບັດລູກຄ້າກ່ຽວກັບ go, ແຕ່ເພີ່ມເຕີມກ່ຽວກັບວ່າຕໍ່ມາ.

ສະຫນັບສະຫນູນດ້ານເຄື່ອງແມ່ຂ່າຍ

ໃນປັດຈຸບັນ, ESNI ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ເຊັ່ນ nginx / apache, ແລະອື່ນໆ, ເນື່ອງຈາກວ່າພວກເຂົາເຮັດວຽກກັບ TLS ຜ່ານ OpenSSL / BoringSSL, ເຊິ່ງບໍ່ສະຫນັບສະຫນູນ ESNI ຢ່າງເປັນທາງການ.

ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈສ້າງອົງປະກອບທາງຫນ້າຂອງພວກເຮົາເອງ (ESNI reverse proxy), ເຊິ່ງສະຫນັບສະຫນູນ TLS 1.3 termination ກັບ ESNI ແລະ proxy HTTP(S) traffic ໄປຫາ upstream, ເຊິ່ງບໍ່ສະຫນັບສະຫນູນ ESNI. ນີ້ອະນຸຍາດໃຫ້ນໍາໃຊ້ເຕັກໂນໂລຢີໃນໂຄງສ້າງພື້ນຖານທີ່ມີຢູ່ແລ້ວ, ໂດຍບໍ່ມີການປ່ຽນແປງອົງປະກອບຕົ້ນຕໍ - ນັ້ນແມ່ນ, ການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍເວັບໃນປະຈຸບັນທີ່ບໍ່ສະຫນັບສະຫນູນ ESNI. 

ເພື່ອຄວາມຊັດເຈນ, ນີ້ແມ່ນແຜນວາດ:

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

ການປະຕິບັດການສະຫນັບສະຫນູນ ESNI ກ່ຽວກັບ go ພວກເຮົາຢືມຈາກ CloudFlare. ຂ້າພະເຈົ້າຢາກຈະສັງເກດເຫັນທັນທີວ່າການຈັດຕັ້ງປະຕິບັດຕົວມັນເອງແມ່ນຂ້ອນຂ້າງບໍ່ສໍາຄັນ, ເພາະວ່າມັນກ່ຽວຂ້ອງກັບການປ່ຽນແປງໃນຫ້ອງສະຫມຸດມາດຕະຖານ. crypto/tls ແລະ​ດັ່ງ​ນັ້ນ​ຈຶ່ງ​ຮຽກ​ຮ້ອງ​ໃຫ້ "patching​" GOROOT ກ່ອນ​ການ​ໂຮມ​ຊຸມນຸມ.

ເພື່ອສ້າງກະແຈ ESNI ພວກເຮົາໃຊ້ esnitool (ຍັງເປັນຄວາມຄິດຂອງ CloudFlare). ກະແຈເຫຼົ່ານີ້ຖືກໃຊ້ສຳລັບການເຂົ້າລະຫັດ/ຖອດລະຫັດ SNI.
ພວກເຮົາໄດ້ທົດສອບການສ້າງໂດຍໃຊ້ go 1.13 ໃນ Linux (Debian, Alpine) ແລະ MacOS. 

ສອງສາມຄໍາກ່ຽວກັບລັກສະນະການດໍາເນີນງານ

ESNI reverse proxy ໃຫ້ metrics ໃນຮູບແບບ Prometheus, ເຊັ່ນ: rps, upstream latency & response codes, failed/successful handshakes & TLS handshake. ຢູ່ glance ທໍາອິດ, ນີ້ເບິ່ງຄືວ່າພຽງພໍທີ່ຈະປະເມີນວິທີການຕົວແທນຈັດການກັບການຈະລາຈອນ. 

ພວກເຮົາຍັງໄດ້ປະຕິບັດການທົດສອບການໂຫຼດກ່ອນການນໍາໃຊ້. ຜົນໄດ້ຮັບຂ້າງລຸ່ມນີ້:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Running 6m test @ https://esni-rev-proxy.npw:443
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.77s     1.21s    7.20s    65.43%
    Req/Sec    13.78      8.84   140.00     83.70%
  206357 requests in 6.00m, 6.08GB read
Requests/sec:    573.07
Transfer/sec:     17.28MB 

ພວກເຮົາໄດ້ປະຕິບັດການທົດສອບການໂຫຼດທີ່ມີຄຸນນະພາບບໍລິສຸດເພື່ອປຽບທຽບໂຄງການໂດຍໃຊ້ ESNI reverse proxy ແລະບໍ່ມີ. ພວກເຮົາ "ຖອກ" ການຈະລາຈອນໃນທ້ອງຖິ່ນເພື່ອກໍາຈັດ "ການແຊກແຊງ" ໃນອົງປະກອບລະດັບກາງ.

ດັ່ງນັ້ນ, ດ້ວຍການສະຫນັບສະຫນູນ ESNI ແລະ proxying ກັບ upstream ຈາກ HTTP, ພວກເຮົາໄດ້ຮັບປະມານ ~ 550 rps ຈາກຕົວຢ່າງຫນຶ່ງ, ດ້ວຍການບໍລິໂພກ CPU / RAM ສະເລ່ຍຂອງ ESNI reverse proxy:

• ການໃຊ້ CPU 80% (4 vCPU, ໂຮສ RAM 4 GB, Linux)
• 130 MB Mem RSS

ສໍາລັບການປຽບທຽບ, RPS ສໍາລັບ nginx upstream ດຽວກັນໂດຍບໍ່ມີການສິ້ນສຸດ TLS (HTTP protocol) ແມ່ນ ~ 1100:

wrk -t50 -c1000 -d360s 'http://lb.npw:80' –-timeout 15s
Running 6m test @ http://lb.npw:80
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.11s     2.30s   15.00s    90.94%
    Req/Sec    23.25     13.55   282.00     79.25%
  393093 requests in 6.00m, 11.35GB read
  Socket errors: connect 0, read 0, write 0, timeout 9555
  Non-2xx or 3xx responses: 8111
Requests/sec:   1091.62
Transfer/sec:     32.27MB 

ການມີເວລາໝົດເວລາຊີ້ບອກວ່າມີການຂາດແຄນຊັບພະຍາກອນ (ພວກເຮົາໄດ້ໃຊ້ vCPU 4 ໂຕ, RAM 4 GB hosts, Linux), ແລະໃນຄວາມເປັນຈິງແລ້ວ RPS ທີ່ມີທ່າແຮງແມ່ນສູງກວ່າ (ພວກເຮົາໄດ້ຮັບຕົວເລກສູງເຖິງ 2700 RPS ໃນຊັບພະຍາກອນທີ່ມີປະສິດທິພາບຫຼາຍກວ່າ).

ສະຫລຸບລວມແລ້ວ, ຂ້າພະເຈົ້າສັງເກດເຫັນ ວ່າເທກໂນໂລຍີ ESNI ເບິ່ງຄືວ່າດີຫຼາຍ. ຍັງມີຫຼາຍຄໍາຖາມເປີດ, ຕົວຢ່າງ, ບັນຫາຂອງການເກັບຮັກສາກະແຈ ESNI ສາທາລະນະໃນ DNS ແລະ rotating ກະແຈ ESNI - ບັນຫາເຫຼົ່ານີ້ໄດ້ຖືກປຶກສາຫາລືຢ່າງຈິງຈັງ, ແລະສະບັບຫລ້າສຸດຂອງຮ່າງ ESNI (ໃນເວລາຂຽນ) ແມ່ນແລ້ວ. 7.

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