Cara nglindhungi situs web umum sampeyan nganggo ESNI

Hai Habr, jenengku Ilya, aku kerja ing tim platform ing Exness. Kita ngembangake lan ngetrapake komponen infrastruktur dhasar sing digunakake dening tim pangembangan produk.

Ing artikel iki, aku pengin nuduhake pengalaman babagan ngetrapake teknologi SNI (ESNI) terenkripsi ing infrastruktur situs web umum.

Panggunaan teknologi iki bakal nambah tingkat keamanan nalika nggarap situs web umum lan tundhuk karo standar keamanan internal sing diadopsi dening Perusahaan.

Kaping pisanan, aku pengin nuduhake manawa teknologi kasebut ora standar lan isih ana ing konsep, nanging CloudFlare lan Mozilla wis ndhukung (ing rancangan01). Iki sing nyebabake kita nindakake eksperimen kasebut.

Minangka teori

ESNI - minangka extension kanggo protokol TLS 1.3 sing ngidini sampeyan ngenkripsi SNI ing pesen salaman TLS "Halo Klien". Mangkene tampilan Hello Klien kanthi dhukungan ESNI (tinimbang SNI biasa, kita ndeleng ESNI):

 Kanggo nggunakake ESNI, telung komponen dibutuhake:

• DNS; 
• Dhukungan pelanggan;
• Dhukungan sisih server.

DNS

Sampeyan kudu nambah rong cathetan DNS - Alan TXT (Catatan TXT ngemot kunci umum sing klien bisa ngenkripsi SNI) - deleng ing ngisor iki. Kajaba iku, kudu ana dhukungan DoH (DNS liwat HTTPS), amarga klien sing kasedhiya (ndeleng ngisor) ora ngaktifake dhukungan ESNI tanpa DoH. Iki logis, amarga ESNI nuduhake enkripsi jeneng sumber sing kita akses, yaiku ora ana gunane kanggo ngakses DNS liwat UDP. Kajaba iku, nggunakake DNSSEC ngijini sampeyan kanggo nglindhungi saka serangan peracunan cache ing skenario iki.

Saiki kasedhiya sawetara panyedhiya DoH, ing antarane:

• cloudflare
• OpenDNS
• Google

cloudflare nyatakake (Priksa Browserku → SNI sing dienkripsi → Sinau Luwih), manawa servere wis ndhukung ESNI, yaiku, kanggo server CloudFlare ing DNS, paling ora ana rong cathetan - A lan TXT. Ing conto ing ngisor iki, kita njaluk Google DNS (liwat HTTPS): 

А entri:

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 rekaman, request kui miturut cithakan _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."
}

Dadi, saka perspektif DNS, kita kudu nggunakake DoH (luwih becik nganggo DNSSEC) lan nambah rong cathetan. 

Dhukungan pelanggan

Yen kita ngomong babagan browser, mula saiki Dhukungan mung dileksanakake ing FireFox. iku instruksi babagan carane ngaktifake dhukungan ESNI lan DoH ing FireFox kasedhiya. Sawise browser dikonfigurasi, kita kudu ndeleng kaya iki:

link kanggo mriksa browser.

Mesthi wae, TLS 1.3 kudu digunakake kanggo ndhukung ESNI, amarga ESNI minangka ekstensi saka TLS 1.3.

Kanggo tujuan nguji backend kanthi dhukungan ESNI, kita ngetrapake klien ing go, Nanging luwih ing mengko.

Dhukungan sisih server

Saiki ESNI ora didhukung dening server web kaya nginx/apache lan liya-liyane, amarga nggarap TLS liwat OpenSSL/BoringSSL, sing ora ndhukung ESNI kanthi resmi.

Pramila kita mutusake kanggo nggawe komponen ngarep dhewe (ESNI reverse proxy), sing bakal ndhukung TLS 1.3 terminasi karo ESNI lan proxying HTTP(S) lalu lintas menyang hulu, sing ora ndhukung ESNI. Iki ngidini nggunakake teknologi ing infrastruktur sing wis ana, tanpa ngganti komponen utama - yaiku, nggunakake server web saiki sing ora ndhukung ESNI. 

Kanggo gamblang, iki diagram:

Aku kaya Wigati sing proxy dirancang karo kemampuan kanggo mungkasi sambungan TLS tanpa ESNI, kanggo ndhukung klien tanpa ESNI. Uga, protokol kanggo komunikasi karo hulu bisa uga HTTP utawa HTTPS kanthi versi TLS ing ngisor 1.3 (yen hulu ora ndhukung 1.3). Skema iki nyedhiyakake keluwesan maksimal.

Implementasi dukungan ESNI ing go kita nyilih saka cloudflare. Aku bakal langsung Wigati sing implementasine dhewe cukup non-trivial, awit iku gawe katut owah-owahan ing perpustakaan standar crypto/tls lan mulane mbutuhake "patching" GOROOT sadurunge perakitan.

Kanggo generate tombol ESNI kita digunakake esnitool (uga nggawe CloudFlare). Tombol iki digunakake kanggo enkripsi / dekripsi SNI.
Kita nguji build kasebut nggunakake go 1.13 ing Linux (Debian, Alpine) lan MacOS. 

Sawetara tembung babagan fitur operasional

Proksi mbalikke ESNI nyedhiyakake metrik ing format Prometheus, kayata rps, latensi hulu & kode respon, salaman TLS gagal/kasil & durasi salaman TLS. Sepisanan, iki cukup kanggo netepake kepiye proxy nangani lalu lintas. 

Kita uga nindakake uji coba sadurunge digunakake. Asil ing ngisor iki:

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 

Kita nganakake tes beban kualitatif murni kanggo mbandhingake skema kasebut kanthi lan tanpa proxy reverse ESNI. Kita "diwutahake" lalu lintas lokal kanggo ngilangi "gangguan" ing komponen penengah.

Dadi, kanthi dhukungan ESNI lan proxy hulu karo HTTP, kita entuk sekitar ~ 550 rps saka siji conto, kanthi rata-rata konsumsi CPU / RAM saka proxy reverse ESNI:

• Panggunaan CPU 80% (4 vCPU, host RAM 4 GB, Linux)
• 130 MB Mem RSS

Kanggo mbandhingake, RPS kanggo hulu nginx sing padha tanpa terminasi TLS (protokol HTTP) yaiku ~ 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 

Anane timeout nuduhake yen ana kekurangan sumber daya (kita nggunakake 4 vCPU, host RAM 4 GB, Linux), lan nyatane potensial RPS luwih dhuwur (kita nampa angka nganti 2700 RPS kanggo sumber daya sing luwih kuat).

Ing kesimpulan, aku pengin dicathet sing teknologi ESNI katon cukup janjeni. Isih akeh pitakonan sing mbukak, contone, masalah nyimpen kunci ESNI umum ing DNS lan muter kunci ESNI - masalah iki aktif dibahas, lan versi paling anyar saka draf (nalika nulis) ESNI wis ana. 7.

Source: www.habr.com