Nola babestu zure webgune publikoa ESNIrekin

Kaixo Habr, nire izena Ilya da, Exness-en plataformako taldean lan egiten dut. Gure produktuak garatzeko taldeek erabiltzen dituzten oinarrizko azpiegitura osagaiak garatzen eta ezartzen ditugu.

Artikulu honetan, webgune publikoen azpiegituran SNI enkriptatutako teknologia (ESNI) ezartzeko nire esperientzia partekatu nahiko nuke.

Teknologia honen erabilerak segurtasun-maila areagotuko du webgune publiko batekin lan egitean eta Enpresak onartutako barne-segurtasun estandarrak beteko ditu.

Lehenik eta behin, adierazi nahi dut teknologia ez dagoela estandarizatua eta oraindik zirriborroan dagoela, baina CloudFlare eta Mozillak dagoeneko onartzen dutela ( zirriborroa01). Horrek motibatu gintuen horrelako esperimentu baterako.

Teoria apur bat

ESNI TLS 1.3 protokoloaren luzapena da, SNI enkriptatzea ahalbidetzen duena TLS esku-ematea "Client Hello" mezuan. Hona hemen Client Hello ESNI laguntzarekin (ohiko SNIaren ordez ESNI ikusten dugu):

 ESNI erabiltzeko, hiru osagai behar dituzu:

• DNS; 
• Bezeroarentzako laguntza;
• Zerbitzariaren aldeko laguntza.

DNS

Bi DNS erregistro gehitu behar dituzu - AEta TXT (TXT erregistroak bezeroak SNI enkriptatu dezakeen gako publikoa dauka) - ikus behean. Horrez gain, laguntza egon behar da DoH (DNS HTTPS bidez), eskuragarri dauden bezeroek (ikus behean) ez dutelako ESNI laguntza gaitzen DoH gabe. Hau logikoa da, ESNIk sartzen garen baliabidearen izena enkriptatzea suposatzen baitu, hau da, ez du zentzurik DNSa UDPren bidez sartzeak. Gainera, erabilera DNSSec agertoki honetan cachearen pozoitze-erasoetatik babesteko aukera ematen du.

Une honetan eskuragarri hainbat DoH hornitzaile, haien artean:

• CloudFlare
• OpenDNS
• Google

CloudFlare estatu (Egiaztatu Nire arakatzailea → SNI enkriptatua → Argibide gehiago) beren zerbitzariek dagoeneko ESNI onartzen dutela, hau da, DNSko CloudFlare zerbitzarientzat gutxienez bi erregistro ditugu - A eta TXT. Beheko adibidean Google DNS kontsultatzen dugu (HTTPS bidez): 

А sarrera:

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 erregistroa, eskaera txantiloi baten arabera sortzen da _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."
}

Beraz, DNS ikuspegitik, DoH erabili beharko genuke (ahal bada DNSSEC) eta bi sarrera gehitu. 

Bezeroarentzako arreta

Nabigatzaileez ari bagara, momentuz laguntza FireFox-en bakarrik ezartzen da. Hemen Hona hemen FireFox-en ESNI eta DoH euskarria nola aktibatzeko argibideak. Arakatzailea konfiguratu ondoren, honelako zerbait ikusi beharko genuke:

Link arakatzailea egiaztatzeko.

Noski, TLS 1.3 erabili behar da ESNI onartzeko, ESNI TLS 1.3rako luzapena baita.

Backend-a ESNI laguntzarekin probatzeko helburuarekin, bezeroa inplementatu dugu go, Baina gehiago gehiago geroago.

Zerbitzariaren aldeko laguntza

Gaur egun, ESNI ez dute onartzen nginx/apache, etab. bezalako web zerbitzariek, TLS-ekin lan egiten baitute OpenSSL/BoringSSL bidez, ofizialki ESNI onartzen ez dutenak.

Hori dela eta, gure frontend osagaia (ESNI alderantzizko proxy) sortzea erabaki genuen, TLS 1.3 amaiera onartzen duena ESNIrekin eta proxy HTTP(S) trafikoa upstream-era, ESNI onartzen ez duena. Horri esker, teknologia lehendik dagoen azpiegitura batean erabil daiteke, osagai nagusiak aldatu gabe, hau da, ESNI onartzen ez duten egungo web zerbitzariak erabiliz. 

Argitasuna lortzeko, hona hemen diagrama bat:

Kontuan izan dut proxy-a ESNIrik gabeko TLS konexioa amaitzeko gaitasunarekin diseinatu zela, ESNIrik gabeko bezeroei laguntzeko. Gainera, upstream-ekin komunikazio-protokoloa HTTP edo HTTPS izan daiteke 1.3 baino txikiagoa den TLS bertsioarekin (upstream 1.3 onartzen ez badu). Eskema honek malgutasun handiena ematen du.

ESNI laguntza ezartzea on go maileguan hartu genuen CloudFlare. Berehala adierazi nahiko nuke inplementazioa bera ez dela hutsala, liburutegi estandarrean aldaketak dakarrelako. kripto/tls eta, beraz, "adabakia" behar da GOROOT muntatu aurretik.

Erabili ditugun ESNI gakoak sortzeko esnitool (Era berean, CloudFlare-ren ideia). Gako hauek SNI enkriptatzeko/deszifratzeko erabiltzen dira.
Eraikuntza go 1.13 erabiliz probatu dugu Linux (Debian, Alpine) eta MacOS-en. 

Ezaugarri operatiboei buruzko hitz batzuk

ESNI alderantzizko proxy-ak neurketak eskaintzen ditu Prometheus formatuan, esate baterako, rps, gorako latentzia eta erantzun kodeak, huts/arrakastatsuak diren TLS esku-emateak eta TLS-ko esku-emateen iraupena. Lehen begiratuan, nahikoa zirudien proxyak trafikoa nola kudeatzen duen ebaluatzeko. 

Erabili aurretik karga probak ere egin ditugu. Jarraian emaitzak:

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 

Karga proba kualitatibo hutsak egin ditugu eskema alderatzeko ESNI alderantzizko proxy erabiliz eta gabe. Trafikoa lokalean "isuri" genuen tarteko osagaietan "interferentziak" ezabatzeko.

Beraz, ESNI laguntzarekin eta HTTP-tik gorako proxyarekin, ~ 550 rps inguru lortu genituen instantzia batetik, ESNI alderantzizko proxyaren batez besteko CPU/RAM kontsumoarekin:

• PUZaren %80ko erabilera (4 vCPU, 4 GB RAM ostalariak, Linux)
• 130 MB Mem RSS

Konparazio baterako, TLS (HTTP protokoloa) amaierarik gabeko nginx berdinerako RPS ~ 1100 da:

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 

Denbora-mugak egoteak baliabide falta dagoela adierazten du (4 vCPU erabili ditugu, 4 GB RAM ostalari, Linux), eta, hain zuzen ere, RPS potentziala handiagoa da (baliabide indartsuagoetan 2700 RPS arteko zifrak jaso ditugu).

Bukatzeko, ohartzen naiz ESNI teknologia nahiko itxaropentsua dela. Oraindik galdera asko daude irekita, adibidez, ESNI gako publikoa DNSn gordetzearen eta ESNI gakoen biratzeari buruzko gaiak - gai horiek aktiboki eztabaidatzen ari dira, eta ESNIren zirriborroaren azken bertsioa (idazteko unean) dago jada. 7.

Iturria: www.habr.com