ProHoster > Blog > Stjórnsýsla > Hvernig á að vernda opinbera vefsíðu þína með ESNI

Hvernig á að vernda opinbera vefsíðu þína með ESNI

Halló Habr, ég heiti Ilya, ég vinn í pallateyminu hjá Exness. Við þróum og innleiðum grunninnviðaíhlutina sem vöruþróunarteymin okkar nota.

Í þessari grein langar mig að deila reynslu minni af innleiðingu dulkóðaðrar SNI (ESNI) tækni í innviði opinberra vefsíðna.

Hvernig á að vernda opinbera vefsíðu þína með ESNI

Notkun þessarar tækni mun auka öryggisstigið þegar unnið er með opinbera vefsíðu og uppfylla innri öryggisstaðla sem fyrirtækið hefur samþykkt.

Í fyrsta lagi vil ég benda á að tæknin er ekki stöðluð og er enn í drögunum, en CloudFlare og Mozilla styðja hana nú þegar (í drög 01). Þetta hvatti okkur til slíkrar tilraunar.

Smá kenning

ESNI er viðbót við TLS 1.3 samskiptareglur sem leyfir SNI dulkóðun í TLS handabandinu „Client Hallo“ skilaboðin. Svona lítur Client Hello út með ESNI stuðningi (í stað venjulegs SNI sjáum við ESNI):

Hvernig á að vernda opinbera vefsíðu þína með ESNI

 Til að nota ESNI þarftu þrjá hluti:

  • DNS; 
  • Stuðningur við viðskiptavini;
  • Stuðningur á netþjóni.

DNS

Þú þarft að bæta við tveimur DNS færslum - AOg TXT (TXT-skráin inniheldur opinbera lykilinn sem viðskiptavinurinn getur dulkóðað SNI með) - sjá hér að neðan. Auk þess þarf að vera til stuðningur DoH (DNS yfir HTTPS) vegna þess að tiltækir viðskiptavinir (sjá hér að neðan) virkja ekki ESNI stuðning án DoH. Þetta er rökrétt, þar sem ESNI gefur til kynna dulkóðun á nafni auðlindarinnar sem við erum að fá aðgang að, það er, það þýðir ekkert að fá aðgang að DNS yfir UDP. Þar að auki, notkun DNSSEC gerir þér kleift að vernda gegn skyndiminni eitrunarárásum í þessari atburðarás.

Í boði eins og er nokkrir DoH veitendur, meðal þeirra:

CloudFlare segir (Athugaðu vafrann minn → Dulkóðað SNI → Lærðu meira) að netþjónar þeirra styðja nú þegar ESNI, það er, fyrir CloudFlare netþjóna í DNS höfum við að minnsta kosti tvær færslur - A og TXT. Í dæminu hér að neðan spyrjum við Google DNS (yfir HTTPS): 

А færsla:

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 skrá, beiðni er búin til samkvæmt sniðmáti _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."
}

Svo, frá DNS sjónarhorni, ættum við að nota DoH (helst með DNSSEC) og bæta við tveimur færslum. 

Þjónustudeild

Ef við erum að tala um vafra, þá í augnablikinu stuðningur er aðeins útfærður í FireFox. Hér Hér eru leiðbeiningar um hvernig á að virkja ESNI og DoH stuðning í FireFox. Eftir að vafrinn hefur verið stilltur ættum við að sjá eitthvað á þessa leið:

Hvernig á að vernda opinbera vefsíðu þína með ESNI

Link til að athuga vafrann.

Auðvitað þarf að nota TLS 1.3 til að styðja ESNI, þar sem ESNI er viðbót við TLS 1.3.

Í þeim tilgangi að prófa stuðninginn með ESNI stuðningi, innleiddum við viðskiptavininn á go, En meira um það síðar.

Stuðningur á netþjóni

Eins og er er ESNI ekki stutt af vefþjónum eins og nginx/apache osfrv., þar sem þeir vinna með TLS í gegnum OpenSSL/BoringSSL, sem styðja ekki opinberlega ESNI.

Þess vegna ákváðum við að búa til okkar eigin framhliðarhluta (ESNI reverse proxy), sem myndi styðja TLS 1.3 lokun með ESNI og proxy HTTP(S) umferð til andstreymis, sem styður ekki ESNI. Þetta gerir kleift að nota tæknina í innviðum sem þegar eru til, án þess að breyta helstu hlutum - það er að nota núverandi vefþjóna sem styðja ekki ESNI. 

Til glöggvunar er hér skýringarmynd:

Hvernig á að vernda opinbera vefsíðu þína með ESNI

Ég tek fram að umboðið var hannað með getu til að slíta TLS tengingu án ESNI, til að styðja viðskiptavini án ESNI. Einnig geta samskiptareglur við andstreymis verið annað hvort HTTP eða HTTPS með TLS útgáfu sem er lægri en 1.3 (ef andstreymis styður ekki 1.3). Þetta kerfi gefur hámarks sveigjanleika.

Innleiðing ESNI-stuðnings á go við fengum lánað hjá CloudFlare. Ég vil taka það strax fram að útfærslan sjálf er frekar ólétt þar sem hún felur í sér breytingar á venjulegu bókasafni dulmál/tls og krefst þess vegna „plástur“ GOROOT fyrir samsetningu.

Til að búa til ESNI lykla notuðum við esnitool (einnig hugarfóstur CloudFlare). Þessir lyklar eru notaðir fyrir SNI dulkóðun/afkóðun.
Við prófuðum bygginguna með go 1.13 á Linux (Debian, Alpine) og MacOS. 

Nokkur orð um rekstrareiginleika

ESNI öfugt umboð veitir mælikvarða á Prometheus sniði, svo sem rps, andstreymis leynd og svarkóða, misheppnuð/velheppnuð TLS handtök og lengd TLS handabands. Við fyrstu sýn virtist þetta nægja til að meta hvernig umboðið höndlar umferð. 

Við gerðum einnig álagspróf fyrir notkun. Niðurstöður hér að neðan:

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 

Við framkvæmdum eingöngu eigindlegar álagsprófanir til að bera saman kerfið með því að nota ESNI öfugt umboð og án þess. Við „helltum“ umferð á staðnum til að útrýma „truflunum“ í millihluta.

Svo, með ESNI stuðningi og umboði til andstreymis frá HTTP, fengum við um ~550 rps frá einu tilviki, með meðaltal örgjörva/vinnsluminni neyslu ESNI öfugs umboðs:

  • 80% örgjörvanotkun (4 vCPU, 4 GB vinnsluminni, Linux)
  • 130 MB Mem RSS

Hvernig á að vernda opinbera vefsíðu þína með ESNI

Til samanburðar er RPS fyrir sama nginx andstreymis án TLS (HTTP siðareglur) uppsögn ~ 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 

Tilvist tímafrests gefur til kynna að það sé skortur á fjármagni (við notuðum 4 vCPU, 4 GB vinnsluminni, Linux), og í raun er möguleiki á RPS hærri (við fengum tölur allt að 2700 RPS á öflugri auðlindum).

Að endingu tek ég fram að ESNI tæknin lítur nokkuð vel út. Það eru enn margar opnar spurningar, til dæmis vandamálin um að geyma opinbera ESNI lykilinn í DNS og snúa ESNI lyklum - þessi mál eru í virkri umræðu og nýjasta útgáfan af ESNI drögunum (þegar þetta er skrifað) er þegar 7.

Heimild: www.habr.com

Bæta við athugasemd