Sut i ddiogelu eich gwefan gyhoeddus gydag ESNI

Helo Habr, fy enw i yw Ilya, rwy'n gweithio yn y tîm platfform yn Exness. Rydym yn datblygu ac yn gweithredu'r cydrannau seilwaith craidd y mae ein timau datblygu cynnyrch yn eu defnyddio.

Yn yr erthygl hon, hoffwn rannu fy mhrofiad o weithredu technoleg SNI (ESNI) wedi'i hamgryptio yn seilwaith gwefannau cyhoeddus.

Bydd defnyddio'r dechnoleg hon yn cynyddu lefel y diogelwch wrth weithio gyda gwefan gyhoeddus ac yn cydymffurfio â safonau diogelwch mewnol a fabwysiadwyd gan y Cwmni.

Yn gyntaf oll, hoffwn nodi nad yw'r dechnoleg wedi'i safoni a'i bod yn dal i fod yn y drafft, ond mae CloudFlare a Mozilla eisoes yn ei gefnogi (yn drafft01). Roedd hyn yn ein hysgogi ar gyfer arbrawf o'r fath.

Darn o theori

ESNI yn estyniad i'r protocol TLS 1.3 sy'n caniatáu amgryptio SNI yn y neges ysgwyd llaw TLS "Cleient Helo". Dyma sut olwg sydd ar Cleient Hello gyda chefnogaeth ESNI (yn lle'r SNI arferol rydym yn gweld ESNI):

 I ddefnyddio ESNI, mae angen tair cydran arnoch chi:

• DNS; 
• cymorth i gleientiaid;
• Cefnogaeth ochr gweinydd.

DNS

Mae angen i chi ychwanegu dau gofnod DNS - AAc TXT (Mae'r cofnod TXT yn cynnwys yr allwedd gyhoeddus y gall y cleient amgryptio SNI ag ef) - gweler isod. Yn ogystal, rhaid cael cefnogaeth DoH (DNS dros HTTPS) oherwydd nad yw cleientiaid sydd ar gael (gweler isod) yn galluogi cymorth ESNI heb Adran Iechyd. Mae hyn yn rhesymegol, gan fod ESNI yn awgrymu amgryptio enw'r adnodd yr ydym yn ei gyrchu, hynny yw, nid yw'n gwneud unrhyw synnwyr cyrchu DNS dros y CDU. Ar ben hynny, y defnydd DNSSEC yn eich galluogi i amddiffyn rhag ymosodiadau gwenwyno cache yn y senario hwn.

Ar gael ar hyn o bryd sawl darparwr yr Adran Iechyd, yn eu plith:

• CloudFlare
• OpenDNS
• google

CloudFlare yn datgan (Gwiriwch Fy Porwr → SNI Amgryptio → Dysgwch Mwy) bod eu gweinyddwyr eisoes yn cefnogi ESNI, hynny yw, ar gyfer gweinyddwyr CloudFlare yn y DNS mae gennym o leiaf ddau gofnod - A a TXT. Yn yr enghraifft isod rydym yn ymholi Google DNS (dros HTTPS): 

А mynediad:

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 cofnod, cynhyrchir cais yn unol â thempled _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."
}

Felly, o safbwynt DNS, dylem ddefnyddio DoH (yn ddelfrydol gyda DNSSEC) ac ychwanegu dau gofnod. 

Cefnogaeth i gwsmeriaid

Os ydym yn sôn am borwyr, yna ar hyn o bryd dim ond yn FireFox y gweithredir cefnogaeth. Yma Dyma gyfarwyddiadau ar sut i actifadu cefnogaeth ESNI a DoH yn FireFox. Ar ôl i'r porwr gael ei ffurfweddu, dylem weld rhywbeth fel hyn:

Cyswllt i wirio'r porwr.

Wrth gwrs, rhaid defnyddio TLS 1.3 i gefnogi ESNI, gan fod ESNI yn estyniad i TLS 1.3.

Er mwyn profi'r backend gyda chefnogaeth ESNI, fe wnaethom weithredu'r cleient ymlaen go, Ond mwy am hynny yn nes ymlaen.

Cefnogaeth ochr gweinydd

Ar hyn o bryd, nid yw ESNI yn cael ei gefnogi gan weinyddion gwe fel nginx/apache, ac ati, gan eu bod yn gweithio gyda TLS trwy OpenSSL/BoringSSL, nad ydynt yn cefnogi ESNI yn swyddogol.

Felly, fe wnaethom benderfynu creu ein cydran pen blaen ein hunain (procsi gwrthdro ESNI), a fyddai’n cefnogi terfynu TLS 1.3 gydag ESNI a thraffig dirprwy HTTP(S) i fyny’r afon, nad yw’n cefnogi ESNI. Mae hyn yn caniatáu i'r dechnoleg gael ei defnyddio mewn seilwaith sydd eisoes yn bodoli, heb newid y prif gydrannau - hynny yw, defnyddio gweinyddwyr gwe cyfredol nad ydynt yn cefnogi ESNI. 

Er eglurder, dyma ddiagram:

Sylwaf fod y dirprwy wedi'i gynllunio gyda'r gallu i derfynu cysylltiad TLS heb ESNI, i gefnogi cleientiaid heb ESNI. Hefyd, gall y protocol cyfathrebu gydag i fyny'r afon fod naill ai HTTP neu HTTPS gyda fersiwn TLS yn is na 1.3 (os nad yw i fyny'r afon yn cefnogi 1.3). Mae'r cynllun hwn yn rhoi'r hyblygrwydd mwyaf posibl.

Gweithredu cymorth ESNI ar go benthyciasom o CloudFlare. Hoffwn nodi ar unwaith bod y gweithrediad ei hun yn eithaf dibwys, gan ei fod yn golygu newidiadau yn y llyfrgell safonol crypto/tls ac felly mae angen “clytio” GOROOT cyn y cynulliad.

I gynhyrchu allweddi ESNI defnyddiwyd esnitool (hefyd syniad CloudFlare). Defnyddir yr allweddi hyn ar gyfer amgryptio/dadgryptio SNI.
Fe wnaethon ni brofi'r adeilad gan ddefnyddio go 1.13 ar Linux (Debian, Alpine) a MacOS. 

Ychydig eiriau am nodweddion gweithredol

Mae dirprwy gwrthdro ESNI yn darparu metrigau ar ffurf Prometheus, megis rps, hwyrni i fyny'r afon a chodau ymateb, ysgwyd llaw TLS sydd wedi methu/llwyddiannus a hyd ysgwyd llaw TLS. Ar yr olwg gyntaf, roedd hyn yn ymddangos yn ddigonol i werthuso sut mae'r dirprwy yn trin traffig. 

Gwnaethom hefyd gynnal profion llwyth cyn eu defnyddio. Canlyniadau isod:

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 

Fe wnaethom gynnal profion llwyth ansoddol yn unig i gymharu'r cynllun gan ddefnyddio gwrthdröydd ESNI a hebddo. Fe wnaethon ni “arllwys” traffig yn lleol er mwyn dileu “ymyrraeth” mewn cydrannau canolradd.

Felly, gyda chefnogaeth ESNI a dirprwy i fyny'r afon o HTTP, cawsom tua ~550 rps o un achos, gyda'r defnydd CPU / RAM cyfartalog o ESNI gwrthdröydd dirprwyol:

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

Er mwyn cymharu, RPS ar gyfer yr un nginx i fyny'r afon heb derfyniad TLS (protocol HTTP) yw ~ 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 

Mae presenoldeb goramser yn dangos bod diffyg adnoddau (fe wnaethom ddefnyddio 4 vCPUs, gwesteiwr RAM 4 GB, Linux), ac mewn gwirionedd mae'r RPS posibl yn uwch (cawsom ffigurau o hyd at 2700 RPS ar adnoddau mwy pwerus).

I gloi, nodaf bod technoleg ESNI yn edrych yn eithaf addawol. Mae yna lawer o gwestiynau agored o hyd, er enghraifft, materion storio allwedd ESNI cyhoeddus yn y DNS a chylchdroi allweddi ESNI - mae'r materion hyn yn cael eu trafod yn weithredol, ac mae fersiwn diweddaraf drafft ESNI (ar adeg ysgrifennu) eisoes 7.

Ffynhonnell: hab.com