Kumaha ngajaga halaman wéb umum anjeun nganggo ESNI

Halo Habr, nami abdi Ilya, abdi damel di tim platform di Exness. Kami ngembangkeun sareng ngalaksanakeun komponén infrastruktur inti anu dianggo ku tim pamekaran produk urang.

Dina tulisan ieu, kuring hoyong ngabagi pangalaman kuring pikeun nerapkeun téknologi SNI (ESNI) énkripsi dina infrastruktur situs wéb umum.

Pamakéan téknologi ieu bakal ningkatkeun tingkat kaamanan nalika damel sareng situs wéb umum sareng sasuai sareng standar kaamanan internal anu diadopsi ku Perusahaan.

Anu mimiti, kuring hoyong nunjukkeun yén téknologi henteu standar sareng masih aya dina draf, tapi CloudFlare sareng Mozilla parantos ngadukung éta (dina draf01). Ieu ngamotivasi kami pikeun percobaan sapertos kitu.

Bit téori

ESNI mangrupa extension ka TLS 1.3 protokol anu ngamungkinkeun enkripsi SNI dina TLS sasalaman "klien Hello" pesen. Ieu kumaha Client Hello sareng dukungan ESNI (gaganti SNI biasa anu urang tingali ESNI):

 Pikeun ngagunakeun ESNI, anjeun peryogi tilu komponén:

• DNS; 
• rojongan klien;
• Pangrojong sisi server.

DNS

Anjeun kedah nambihan dua rékaman DNS - Ajeung TXT (Catatan TXT ngandung konci umum nu klien bisa encrypt SNI) - tingali di handap. Sajaba ti éta, kudu aya rojongan DoH (DNS leuwih HTTPS) sabab klien sadia (tempo di handap) teu ngaktipkeun rojongan ESNI tanpa DoH. Ieu logis, sabab ESNI nunjukkeun énkripsi nami sumber anu kami diaksés, nyaéta, teu aya akal pikeun ngaksés DNS liwat UDP. Leuwih ti éta, pamakéan DNSSEC ngidinan Anjeun ngajaga ngalawan serangan karacunan cache dina skenario ieu.

Ayeuna aya sababaraha panyadia DoH, diantara aranjeunna:

• CloudFlare
• OpenDNS
• Google

CloudFlare ngumumkeun (Pariksa Browser abdi → Énkripsi SNI → Diajar More) yén server maranéhanana geus ngarojong ESNI, nyaeta, pikeun server CloudFlare dina DNS urang boga sahanteuna dua rékaman - A jeung TXT. Dina conto di handap ieu kami naroskeun Google DNS (ngaliwatan 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 rékaman, pamundut dihasilkeun nurutkeun citakan _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."
}

Janten, tina sudut pandang DNS, urang kedah nganggo DoH (preferably sareng DNSSEC) sareng nambihan dua éntri. 

rojongan customer

Lamun urang keur diajak ngobrol ngeunaan browser, teras di momen rojongan dilaksanakeun ngan dina Firefox. Ieu téh Ieu pitunjuk ngeunaan cara ngaktipkeun dukungan ESNI sareng DoH di FireFox. Saatos browser dikonpigurasi, urang kedah ningali sapertos kieu:

link pikeun mariksa browser.

Tangtosna, TLS 1.3 kedah dianggo pikeun ngadukung ESNI, sabab ESNI mangrupikeun ekstensi pikeun TLS 1.3.

Pikeun tujuan nguji backend kalayan rojongan ESNI, kami dilaksanakeun klien on go, Tapi nu langkung lengkep ihwal nu engké.

Pangrojong sisi server

Ayeuna, ESNI henteu dirojong ku pangladén wéb sapertos nginx/apache, jsb., sabab tiasa dianggo sareng TLS via OpenSSL/BoringSSL, anu henteu sacara resmi ngadukung ESNI.

Ku alatan éta, urang mutuskeun nyieun komponén hareup-tungtung urang sorangan (ESNI reverse proxy), nu bakal ngarojong TLS 1.3 terminasi kalawan ESNI jeung proxy HTTP(S) lalulintas ka hulu, nu teu ngarojong ESNI. Hal ieu ngamungkinkeun téhnologi pikeun dipaké dina infrastruktur geus aya, tanpa ngarobah komponén utama - nyaeta, ngagunakeun web server ayeuna nu teu ngarojong ESNI. 

Pikeun kajelasan, ieu diagram:

Kuring dicatet yén proxy ieu dirancang kalayan kamampuhan pikeun ngeureunkeun sambungan TLS tanpa ESNI, pikeun ngarojong klien tanpa ESNI. Ogé, protokol komunikasi sareng hulu tiasa HTTP atanapi HTTPS kalayan versi TLS langkung handap tina 1.3 (upami hulu henteu ngadukung 1.3). Skéma ieu masihan kalenturan maksimal.

Palaksanaan rojongan ESNI on go urang injeuman ti CloudFlare. Abdi hoyong langsung perhatikeun yén palaksanaanna sorangan henteu sepele, sabab éta ngalibatkeun parobahan dina perpustakaan standar. crypto/tls ku kituna merlukeun "patching" GOROOT saméméh assembly.

Pikeun ngahasilkeun konci ESNI kami dipaké esnitool (ogé gagasan CloudFlare). Konci ieu dianggo pikeun énkripsi / dekripsi SNI.
Kami nguji ngawangun nganggo go 1.13 dina Linux (Debian, Alpine) sareng MacOS. 

Sababaraha kecap ngeunaan fitur operasional

Proksi sabalikna ESNI nyayogikeun métrik dina format Prometheus, sapertos rps, latency hulu & kode réspon, sasalaman TLS anu gagal / suksés & durasi sasalaman TLS. Dina glance kahiji, ieu sigana cukup keur evaluate kumaha proxy handles lalulintas. 

Kami ogé ngalaksanakeun uji beban sateuacan dianggo. Hasilna di handap:

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 

Kami ngalaksanakeun uji beban kualitatif murni pikeun ngabandingkeun skéma nganggo proxy sabalikna ESNI sareng tanpa. Urang "tuang" lalulintas lokal guna ngaleungitkeun "gangguan" dina komponén panengah.

Janten, kalayan dukungan ESNI sareng proksi ka hulu ti HTTP, urang ngagaduhan sakitar ~ 550 rps tina hiji conto, kalayan rata-rata konsumsi CPU / RAM tina proxy sabalikna ESNI:

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

Pikeun babandingan, RPS pikeun nginx sami hulu tanpa TLS (HTTP protokol) terminasi ~ 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 

Ayana timeouts nunjukkeun yén aya kakurangan sumberdaya (urang dipaké 4 vCPUs, 4 GB RAM sarwa, Linux Ubuntu), sarta dina kanyataanana poténsi RPS leuwih luhur (urang nampi angka nepi ka 2700 RPS on sumberdaya leuwih kuat).

Dina kacindekan, kuring nyatet yén téhnologi ESNI Sigana rada ngajangjikeun. Masih seueur patarosan anu kabuka, contona, masalah nyimpen konci ESNI umum dina DNS sareng konci ESNI puteran - masalah ieu nuju dibahas sacara aktip, sareng versi panganyarna tina draf ESNI (dina waktos nyerat) parantos aya. 7.

sumber: www.habr.com