ProHoster > Blogs > Administrācija > Kā aizsargāt savu publisko vietni ar ESNI

Kā aizsargāt savu publisko vietni ar ESNI

Sveiki, Habr, mani sauc Iļja, es strādāju Exness platformas komandā. Mēs izstrādājam un ievieÅ”am galvenos infrastruktÅ«ras komponentus, ko izmanto mÅ«su produktu izstrādes komandas.

Å ajā rakstā vēlos dalÄ«ties pieredzē par Å”ifrētas SNI (ESNI) tehnoloÄ£ijas ievieÅ”anu publisko vietņu infrastruktÅ«rā.

Kā aizsargāt savu publisko vietni ar ESNI

Å Ä«s tehnoloÄ£ijas izmantoÅ”ana paaugstinās droŔības lÄ«meni, strādājot ar publisku vietni, un atbildÄ«s SabiedrÄ«bas pieņemtajiem iekŔējās droŔības standartiem.

Pirmkārt, vēlos norādÄ«t, ka tehnoloÄ£ija nav standartizēta un joprojām ir melnrakstā, bet CloudFlare un Mozilla to jau atbalsta (in projekts01). Tas mÅ«s motivēja Ŕādam eksperimentam.

Mazliet teorija

ESNI ir TLS 1.3 protokola paplaÅ”inājums, kas ļauj SNI Å”ifrēt TLS rokasspiediena ziņojumā ā€œClient Helloā€. LÅ«k, kā Client Hello izskatās ar ESNI atbalstu (parastā SNI vietā mēs redzam ESNI):

Kā aizsargāt savu publisko vietni ar ESNI

 Lai izmantotu ESNI, jums ir nepiecieÅ”ami trÄ«s komponenti:

  • DNS; 
  • Klientu atbalsts;
  • Servera puses atbalsts.

DNS

Jums jāpievieno divi DNS ieraksti - AUn TXT (TXT ieraksts satur publisko atslēgu, ar kuru klients var Å”ifrēt SNI) - skatiet tālāk. Turklāt ir jābÅ«t atbalstam DoH (DNS, izmantojot HTTPS), jo pieejamie klienti (skatiet tālāk) neiespējo ESNI atbalstu bez DoH. Tas ir loÄ£iski, jo ESNI nozÄ«mē tā resursa nosaukuma Å”ifrÄ“Å”anu, kuram mēs piekļūstam, tas ir, nav jēgas piekļūt DNS, izmantojot UDP. Turklāt lietoÅ”ana DNSSEC ļauj aizsargāties pret keÅ”atmiņas saindÄ“Å”anās uzbrukumiem Å”ajā scenārijā.

Šobrīd pieejams vairāki DoH pakalpojumu sniedzēji, starp viņiem:

CloudFlare deklarē (Pārbaudiet Mana pārlÅ«kprogramma ā†’ Å ifrēts SNI ā†’ Uzziniet vairāk), ka viņu serveri jau atbalsta ESNI, tas ir, CloudFlare serveriem DNS ir vismaz divi ieraksti - A un TXT. Tālāk esoÅ”ajā piemērā mēs vaicājam Google DNS (izmantojot HTTPS): 

Š ieraksts:

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 ieraksts, pieprasījums tiek ģenerēts saskaņā ar veidni _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."
}

Tātad, no DNS viedokļa, mums vajadzētu izmantot DoH (vēlams ar DNSSEC) un pievienot divus ierakstus. 

Klientu atbalsts

Ja mēs runājam par pārlÅ«kprogrammām, tad Å”obrÄ«d atbalsts tiek ieviests tikai FireFox. Å eit Å eit ir norādÄ«jumi par ESNI un DoH atbalsta aktivizÄ“Å”anu FireFox. Kad pārlÅ«kprogramma ir konfigurēta, mums vajadzētu redzēt kaut ko lÄ«dzÄ«gu:

Kā aizsargāt savu publisko vietni ar ESNI

Saite lai pārbaudītu pārlūkprogrammu.

Protams, ESNI atbalstam ir jāizmanto TLS 1.3, jo ESNI ir TLS 1.3 paplaÅ”inājums.

Lai pārbaudītu aizmugursistēmu ar ESNI atbalstu, mēs ieviesām klientu uz go, Bet par to vairāk vēlāk.

Servera puses atbalsts

PaÅ”laik ESNI neatbalsta tÄ«mekļa serveri, piemēram, nginx/apache utt., jo tie darbojas ar TLS, izmantojot OpenSSL/BoringSSL, kas oficiāli neatbalsta ESNI.

Tāpēc mēs nolēmām izveidot savu priekÅ”gala komponentu (ESNI reverso starpniekserveri), kas atbalstÄ«tu TLS 1.3 izbeigÅ”anu ar ESNI un starpniekservera HTTP(S) trafiku uz augÅ”upstraumi, kas neatbalsta ESNI. Tas ļauj tehnoloÄ£iju izmantot jau esoŔā infrastruktÅ«rā, nemainot galvenās sastāvdaļas - tas ir, izmantojot paÅ”reizējos tÄ«mekļa serverus, kas neatbalsta ESNI. 

Skaidrības labad Ŕeit ir diagramma:

Kā aizsargāt savu publisko vietni ar ESNI

Es atzÄ«mēju, ka starpniekserveris tika izstrādāts ar iespēju pārtraukt TLS savienojumu bez ESNI, lai atbalstÄ«tu klientus bez ESNI. ArÄ« saziņas protokols ar augÅ”upeju var bÅ«t HTTP vai HTTPS ar TLS versiju, kas ir zemāka par 1.3 (ja augÅ”upējais neatbalsta 1.3). Å Ä« shēma nodroÅ”ina maksimālu elastÄ«bu.

ESNI atbalsta ievieÅ”ana gada go aizņēmāmies no CloudFlare. Uzreiz vēlos atzÄ«mēt, ka pati ievieÅ”ana ir diezgan nenozÄ«mÄ«ga, jo tā ietver izmaiņas standarta bibliotēkā crypto/tls un tāpēc ir nepiecieÅ”ama ā€œlāpÄ«Å”anaā€ GOROOT pirms montāžas.

Lai Ä£enerētu ESNI atslēgas, mēs izmantojām esnitool (arÄ« CloudFlare ideja). Å Ä«s atslēgas tiek izmantotas SNI Å”ifrÄ“Å”anai/atÅ”ifrÄ“Å”anai.
Mēs pārbaudÄ«jām bÅ«vējumu, izmantojot go 1.13 operētājsistēmās Linux (Debian, Alpine) un MacOS. 

Daži vārdi par darbības īpaŔībām

ESNI reversais starpniekserveris nodroÅ”ina metriku Prometheus formātā, piemēram, rps, augÅ”upvērsto latentuma un atbildes kodus, neveiksmÄ«gus/veiksmÄ«gus TLS rokasspiedienus un TLS rokasspiediena ilgumu. No pirmā acu uzmetiena tas Ŕķita pietiekami, lai novērtētu, kā starpniekserveris apstrādā trafiku. 

Pirms lietoŔanas veicām arī slodzes pārbaudi. Rezultāti zemāk:

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 

Mēs veicām tÄ«ri kvalitatÄ«vu slodzes testÄ“Å”anu, lai salÄ«dzinātu shēmu, izmantojot ESNI reverso starpniekserveri un bez tā. Mēs ā€œielējāmā€ satiksmi lokāli, lai novērstu ā€œtraucējumusā€ starpkomponentos.

Tātad, izmantojot ESNI atbalstu un starpniekserveri uz augÅ”up no HTTP, mēs saņēmām aptuveni 550 rps no vienas instances ar ESNI reversā starpniekservera vidējo CPU/RAM patēriņu:

  • 80% CPU lietojums (4 vCPU, 4 GB RAM resursdatori, Linux)
  • 130 MB atmiņas RSS

Kā aizsargāt savu publisko vietni ar ESNI

Salīdzinājumam, RPS tam paŔam nginx augŔpus bez TLS (HTTP protokola) pārtraukŔanas ir ~ 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 

Taimautu klātbūtne norāda uz resursu trūkumu (izmantojām 4 vCPU, 4 GB RAM resursdatorus, Linux), un patiesībā potenciālais RPS ir lielāks (saņēmām skaitļus līdz 2700 RPS jaudīgākiem resursiem).

Noslēgumā es atzÄ«mēju ka ESNI tehnoloÄ£ija izskatās diezgan daudzsoloÅ”i. Joprojām ir daudz atklātu jautājumu, piemēram, jautājumi par publiskās ESNI atslēgas glabāŔanu DNS un ESNI atslēgu rotāciju - Å”ie jautājumi tiek aktÄ«vi apspriesti, un ESNI projekta jaunākā versija (raksta tapÅ”anas brÄ«dÄ«) jau ir pieejama. 7.

Avots: www.habr.com

Pievieno komentāru