🥇Како заштитити своју јавну веб страницу помоћу ЕСНИ-а

Здраво Хабр, моје име је Иља, радим у тиму платформе у Екнессу. Развијамо и имплементирамо основне компоненте инфраструктуре које користе наши тимови за развој производа.

У овом чланку желим да поделим своје искуство у примени шифроване СНИ (ЕСНИ) технологије у инфраструктури јавних веб локација.

Употреба ове технологије ће повећати ниво безбедности при раду са јавном веб-страницом и бити усклађена са интерним безбедносним стандардима које је усвојила Компанија.

Пре свега, желео бих да истакнем да технологија није стандардизована и да је још увек у нацрту, али је ЦлоудФларе и Мозилла већ подржавају (у драфт01). То нас је мотивисало за овакав експеримент.

Мало теорије

ЕСНИ је проширење за ТЛС 1.3 протокол који омогућава СНИ шифровање у ТЛС руковању „Здраво клијенту“ поруци. Ево како Цлиент Хелло изгледа са ЕСНИ подршком (уместо уобичајеног СНИ видимо ЕСНИ):

Да бисте користили ЕСНИ, потребне су вам три компоненте:

ДНС;
Подршка клијентима;
Подршка на страни сервера.

ДНС

Морате да додате два ДНС записа – AИ ТКСТ (ТКСТ запис садржи јавни кључ са којим клијент може да шифрује СНИ) – види испод. Осим тога, мора постојати подршка ДоХ (ДНС преко ХТТПС-а) јер доступни клијенти (погледајте доле) не омогућавају ЕСНИ подршку без ДоХ-а. Ово је логично, пошто ЕСНИ подразумева шифровање имена ресурса коме приступамо, односно нема смисла приступати ДНС-у преко УДП-а. Штавише, употреба ДНССЕЦ вам омогућава да се заштитите од напада тровања кеша у овом сценарију.

Тренутно доступан неколико ДоХ провајдера, међу њима:

ЦлоудФларе изјављује (Цхецк Ми Бровсер → Енцриптед СНИ → Леарн Море) да њихови сервери већ подржавају ЕСНИ, односно за ЦлоудФларе сервере у ДНС-у имамо најмање два записа - А и ТКСТ. У примеру испод постављамо упит за Гоогле ДНС (преко ХТТПС-а):

А унос:

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"
    }
  ]
}

ТКСТ запис, захтев се генерише према шаблону _есни.ФКДН:

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."
}

Дакле, из перспективе ДНС-а, требало би да користимо ДоХ (пожељно са ДНССЕЦ) и додамо два уноса.

Подршка муштеријама

Ако говоримо о претраживачима, онда у овом тренутку подршка је имплементирана само у ФиреФок-у. Овде Ево инструкција како да активирате ЕСНИ и ДоХ подршку у ФиреФок-у. Након што је претраживач конфигурисан, требало би да видимо нешто овако:

Линк да проверите претраживач.

Наравно, ТЛС 1.3 се мора користити за подршку ЕСНИ, пошто је ЕСНИ проширење за ТЛС 1.3.

У сврху тестирања позадине са ЕСНИ подршком, имплементирали смо клијент на go, Али више о томе касније.

Подршка на страни сервера

Тренутно, ЕСНИ не подржавају веб сервери као што су нгинк/апацхе, итд., пошто они раде са ТЛС-ом преко ОпенССЛ/БорингССЛ-а, који званично не подржавају ЕСНИ.

Због тога смо одлучили да креирамо сопствену фронт-енд компоненту (ЕСНИ реверсе проки), која би подржала ТЛС 1.3 терминацију са ЕСНИ и прокси ХТТП(С) саобраћајем ка узводном, који не подржава ЕСНИ. Ово омогућава да се технологија користи у већ постојећој инфраструктури, без промене главних компоненти – односно коришћење тренутних веб сервера који не подржавају ЕСНИ.

Ради јасноће, ево дијаграма:

Напомињем да је прокси дизајниран са могућношћу да прекине ТЛС везу без ЕСНИ, да подржи клијенте без ЕСНИ. Такође, комуникациони протокол са узводним путем може бити или ХТТП или ХТТПС са ТЛС верзијом нижом од 1.3 (ако упстреам не подржава 1.3). Ова шема даје максималну флексибилност.

Имплементација ЕСНИ подршке на go позајмили смо од ЦлоудФларе. Желео бих одмах да приметим да је сама имплементација прилично нетривијална, јер укључује промене у стандардној библиотеци црипто/тлс и стога захтева "крпање" ГОРООТ пре монтаже.

За генерисање ЕСНИ кључева смо користили еснитоол (такође замисао ЦлоудФларе-а). Ови кључеви се користе за СНИ шифровање/дешифровање.
Тестирали смо верзију користећи go 1.13 на Linux (Debian, Alpine) и MacOS.

Неколико речи о оперативним карактеристикама

ЕСНИ обрнути прокси пружа метрику у Прометхеус формату, као што су рпс, узводно кашњење и кодови одговора, неуспела/успешна ТЛС руковања и трајање ТЛС руковања. На први поглед, ово је изгледало довољно да се процени како прокси управља саобраћајем.

Такође смо извршили тестирање оптерећења пре употребе. Резултати испод:

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

Извршили смо чисто квалитативно тестирање оптерећења да бисмо упоредили шему помоћу ЕСНИ обрнутог проксија и без њега. Локално смо „сипали“ саобраћај како бисмо елиминисали „сметње“ у међукомпонентама.

Дакле, са подршком за ЕСНИ и проксијањем ка узводном од ХТТП-а, добили смо око ~550 рпс из једне инстанце, са просечном потрошњом ЦПУ/РАМ-а ЕСНИ обрнутог проксија:

80% искоришћења процесора (4 vCPU, 4 GB RAM хоста, Linux)
130 МБ Мем РСС

Поређења ради, РПС за исти нгинк узводно без ТЛС (ХТТП протокол) завршетка је ~ 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

Присуство тајм-аута указује на недостатак ресурса (користили смо 4 vCPU, 4 GB RAM хоста, Linux), и заправо је потенцијални RPS већи (добили смо бројке до 2700 RPS на моћнијим ресурсима).

У закључку, напомињем да ЕСНИ технологија изгледа прилично обећавајуће. Још увек има много отворених питања, на пример, питања складиштења јавног ЕСНИ кључа у ДНС-у и ротирања ЕСНИ кључева - о овим питањима се активно расправља, а најновија верзија ЕСНИ нацрта (у време писања) је већ објављена. 7.

Извор: ввв.хабр.цом