🥇Kuidas kaitsta oma avalikku saiti ESNI abil

Tere, Habr! Minu nimi on Ilja ja ma töötan Exnessi platvormimeeskonnas. Me arendame ja rakendame põhistruktuuri komponente, mida kasutavad meie toote arendusmeeskonnad.

Selles artiklis sooviksin jagada kogemust, kuidas me rakendasime tehnoloogiat, mida nimetatakse encrypted SNI (ESNI), avalike veebisaitide infrastruktuuris.

Selle tehnoloogia kasutamine tõstab turvalisuse taset avaliku veebisaidi kasutamisel ja vastab ettevõtte sisemistele turvastandarditele.

Esiteks, soovin tähelepanu juhtida sellele, et tehnoloogia ei ole standardiseeritud ja on endiselt kavandi staatuses, kuid CloudFlare ja Mozilla toetavad seda juba ( draft01). Just see motiveeris meid selliseks eksperimentimiseks.

Veidi teooriat

ESNI on TLS 1.3 protokolli laiendus, mis võimaldab šifreerida SNI TLS handshake'i "Client Hello" sõnumis. Nii näeb välja Client Hello ESNI toega (tavalise SNI asemel näeme ESNI-d):

ESNI kasutamiseks on vajalik kolm komponenti:

DNS;
Tugivõimalus kliendilt;
Tugivõimalus serverilt.

DNS

Peame lisama kaks DNS-i kirjet – A, ja TXT (TXT kirje sisaldab avalikku võtit, mille abil klient saab SNI-d šifreerida) – vt allpool. Lisaks peab olema tugi DoH (DNS over HTTPS), kuna saadaval olevad kliendid (vt allpool) ei aktiveeri ESNI toetust ilma DoH-ta. See on loogiline, kuna ESNI tähendab, et ressursside nime šifreeritakse, st pole mõtet pöörduda DNS-i poole UDP kaudu. Veelgi enam, DNSSEC aitab kaitsta "cache poisoning" rünnakute eest selles stsenaariumis.

Praegu on saadaval mitmeid DoH teenusepakkujaid,sealhulgas:

CloudFlare teatab (Check My Browser → Encrypted SNI → Learn More), et nende serverid toetavad juba praegu ESNI-d, seega CloudFlare'i serverite jaoks DNS-is on meil vähemalt kaks kirjet – A ja TXT. Allolevas näites küsime Google DNS-i (HTTPS-i kaudu):

A kirje:

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 kirje, päring moodustatakse järgmiselt _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."
}

Nii, DNS-i seisukohalt peab me kasutama DoH-i (soovitavalt koos DNSSEC-iga) ja lisama kaks kirjet.

Kliendi tugi

Kui me räägime brauseritest, siis praegu tugi on ellu viidud ainult FireFoxis. Siin siin on juhis, kuidas aktiveerida ESNI ja DoH tugi FireFoxis. Kui brauser on seadistatud, peaksime nägema umbes sellist pilti:

Link brauseri kontrollimiseks.

Muidugi peab ESNI toetamiseks olema kasutusel TLS 1.3, kuna ESNI on TLS 1.3 laiendus.

ESNI toega tagapinna testimise eesmärkidel oleme ellu viinud kliendi go, kuid sellest räägime hiljem.

Serveri tugi

Praegu ei toeta ESNI veebiserverid nagu nginx/apache jne, kuna nad töötavad TLS-iga OpenSSL/BoringSSL kaudu, milles ESNI ametlikult ei ole toetatud.

Seetõttu otsustasime luua oma front-end komponendi (ESNI reverse proxy), mis toetaks TLS 1.3 terminatsiooni ESNI-ga ja HTTP(S) liikluse edastamist upstream-i, mis ei toeta ESNI-d. See võimaldab tehnoloogiat rakendada juba olemasolevas infrastruktuuris, ilma põhiliste komponentide muutmiseta – st kasutada praeguseid veebiservereid, mis ei toeta ESNI-d.

Selguse huvides toome välja skeemi:

Tahan märkida, et proxy on mõeldud TLS-ühenduse terminatsiooniks ilma ESNI-ta, et toetada kliente, kellel ei ole ESNI-d. Samuti võib suhtlusprotokoll upstream-iga olla nii HTTP kui ka HTTPS, kus TLS versioon on alla 1.3 (kui upstream ei toeta 1.3). Selline skeem pakub maksimaalset paindlikkust.

ESNI toe rakendamine go oleme laenanud CloudFlare. Tahan kohe märkida, et rakendus ise on üsna keeruline, kuna see hõlmab muudatusi tavapärases teegis crypto/tls ja seetõttu nõuab see 'patchimist' GOROOT enne kompileerimist.

ESNI võtmete genereerimiseks kasutasime esnitool (see on samuti CloudFlare'i looming). Need võtmed kasutatakse SNI krüpteerimiseks/dekrüpteerimiseks.
Oleme testinud koondise kasutades go 1.13 Linuxis (Debian, Alpine) ja MacOS-is.

Mõned sõnad tööalaste omaduste kohta

ESNI reverse proxy pakub metrikat Prometheuse formaadis, näiteks rps, upstream latentsus & vastuse koodid, ebaõnnestunud/õnnestunud TLS käepigistused & TLS käepigistuse kestus. Esmapilgul tundus see piisav, et hinnata, kuidas proxy liiklusega toime tuleb.

Samuti viisime enne kasutamist läbi koormustestimise. Tulemused on allpool:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Käivitamine 6m testi aadressil https://esni-rev-proxy.npw:443
  50 lõime ja 1000 ühendust
  Lõime statistika   Keskmine      Standardhälve     Max   +/– Standardhälve
    Latentsus     1.77s     1.21s    7.20s    65.43%
    Req/Sek    13.78      8.84   140.00     83.70%
  206357 päringut 6.00m, 6.08GB loetud
Päringud/sec:    573.07
Ülekande/sec:     17.28MB

Koormustestimise viisime läbi puhtalt kvalitatiivselt, et võrrelda skeeme, kasutades ESNI reverse proxy-d ja ilma. Suunasime liiklust kohapeal, et välistada “häireid” vahekomponentides.

Seega, koos ESNI toetuse ja proxied HTTP upstream'iga, saime ligi ~ 550 rps ühest instantsist, kusjuures ESNI reverse proxy keskmine CPU/RAM tarbimine:

80% CPU kasutus (4 vCPU, 4 GB RAM hostid, Linux)
130 MB Mem RSS

Võrdluseks, RPS sama upstreami jaoks nginx ilma TLS terminatsioonita (HTTP protokoll) ~ 1100:

wrk -t50 -c1000 -d360s 'http://lb.npw:80' –-timeout 15s
Käivitamine 6m testi aadressil http://lb.npw:80
  50 lõime ja 1000 ühendust
  Lõime statistika   Keskmine      Standardhälve     Max   +/– Standardhälve
    Latentsus     1.11s     2.30s   15.00s    90.94%
    Req/Sek    23.25     13.55   282.00     79.25%
  393093 päringut 6.00m, 11.35GB loetud
  Socketi vead: ühendus 0, lugemine 0, kirjutamine 0, aegumise 9555
  Non-2xx või 3xx vastused: 8111
Päringud/sec:   1091.62
Ülekande/sec:     32.27MB

Aegumiste olemasolu viitab ressursipuudusele (kasutasime 4 vCPU, 4 GB RAM hostid, Linux), ja tegelikult on potentsiaalne RPS kõrgem (saime numbreid kuni 2700 RPS võimsamatel ressurssidel).

Kokkuvõtteks nendin, et tehnoloogia ESNI näib piisavalt lootustandev. On veel palju lahendamata küsimusi, näiteks avaliku ESNI võtme hoidmine DNS-is ja ESNI võtmete rotatsioon – neid küsimusi arutatakse aktiivselt, ja viimane versioon projektist (kirjutamise hetkel) ESNI on juba 7.

Allikas: habr.com

Kuidas kaitsta oma avalikku saiti ESNI-ga

Veidi teooriat

DNS

Kliendi tugi

Serveri tugi

Mõned sõnad tööalaste omaduste kohta