🥇Как да защитим публичния си сайт с ESNI

Здравейте Хабр, казвам се Иля и работя в платформения екип на компанията Exness. Ние разработваме и внедряваме основни инфраструктурни компоненти, които използват нашите продуктови екипи за разработка.

В тази статия бих искал да споделя опита си от внедряването на технологията encrypted SNI (ESNI) в инфраструктурата на публични уебсайтове.

Използването на тази технология ще повиши нивото на сигурност при работа с публичен уебсайт и ще отговори на вътрешните стандарти за сигурност, приети в Компанията.

Преди всичко искам да подчертая, че технологията не е стандартизирана и все още се намира в чернова, но CloudFlare и Mozilla вече я поддържат (в draft01). Това ни мотивира да извършим този експеримент.

Няколко теории

ESNI е разширение на протокола TLS 1.3, което позволява шифроване на SNI в съобщението „Client Hello“ по време на TLS handshake. Ето как изглежда Client Hello с поддръжка на ESNI (вместо обичайното SNI виждаме ESNI):

За да използвате ESNI, са необходими три основни компонента:

DNS;
Подкрепа от страна на клиента;
Подкрепа от страна на сървера.

DNS

Необходимо е да добавите две DNS записа – A, и TXT (TXT записът съдържа публичния ключ, с който клиентът може да шифрова SNI) – вижте по-долу. Освен това, трябва да има поддръжка на DoH (DNS over HTTPS), тъй като наличните клиенти (вижте по-долу) не активират поддръжката на ESNI без DoH. Това е логично, тъй като ESNI предполага шифроване на името на ресурса, към който се обръщаме, следователно е безсмислено да се свързвате с DNS по UDP. Освен това, използването на DNSSEC дава възможност да се защитите от атаки на „cache poisoning“ в този сценарий.

В момента има достъпни няколко DoH провайдера, сред които:

CloudFlare обявява (Check My Browser → Encrypted SNI → Learn More), че техните сървъри вече поддържат ESNI, което означава, че за сървърите на CloudFlare в DNS имаме поне две записа – A и TXT. В примера по-долу правим запитване към Google DNS (по HTTPS):

И запис:

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 запис, запитването се формира по шаблон _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": "Отговор от 2400:cb00:2049:1::a29f:209."
}

Следователно, от гледна точка на DNS, трябва да използваме DoH (предпочитателно с DNSSEC) и да добавим две записа.

Подкрепа от страна на клиента

Ако говорим за браузъри, в момента подкрепата е реализирана само в FireFox. Тук е предоставено ръководство как да активирате подкрепата за ESNI и DoH в FireFox. След като браузърът е настроен, трябва да видим нещо подобно:

Линк за проверка на браузъра.

Разбира се, за подкрепа на ESNI трябва да се използва TLS 1.3, тъй като ESNI е разширение на TLS 1.3.

За целите на тестването на бекенда с подкрепа за ESNI реализирахме клиент на go, но за това по-късно.

Подкрепа от страна на сървъра

В момента ESNI не се поддържа от уеб сървъри като nginx/apache и т.н., тъй като те работят с TLS посредством OpenSSL/BoringSSL, в които ESNI официално не се поддържа.

Затова решихме да създадем свой front-end компонент (ESNI reverse proxy), който да поддържа терминализация на TLS 1.3 с ESNI и проксирване на HTTP(S) трафик към апстрийм, който не поддържа ESNI. Това позволява използването на технологията в вече съществуваща инфраструктура, без да се променят основните компоненти – т.е. да се използват текущите уеб сървъри, които не поддържат ESNI.

За нагледност представяме схема:

Искам да отбележа, че проксито е замислено с възможност за терминализиране на TLS връзка без ESNI, за подкрепа на клиенти без ESNI. Също така, протоколът за комуникация с апстрийм може да бъде както HTTP, така и HTTPS с версия на TLS под 1.3 (ако апстриймът не поддържа 1.3). Тази схема предоставя максимална гъвкавост.

Реализацията на подкрепата за ESNI на go заемахме от CloudFlare. Веднага отбелязвам, че самата реализация е доста нетривиална, тъй като предполага промени в стандартната библиотека crypto/tls и следователно изисква "пачинг" GOROOT преди компилиране.

За генериране на ESNI ключове използвахме esnitool (също творение на CloudFlare). Тези ключове се използват за криптиране/декриптиране на SNI.
Тествахме компилацията с използване на go 1.13 на Linux (Debian, Alpine) и MacOS.

Няколко думи за експлоатационните особености

ESNI обратният прокси предоставя метрики в формат Prometheus, като например rps, латентност на upstream и кодове за отговор, брой неуспешни/успешни TLS handshake и продължителност на TLS handshake. На пръв поглед това изглеждаше достатъчно, за да се оценят способностите на проксито да работи с трафика.

Също така, преди да използваме, извършихме натоварващо тестване. Резултатите са по-долу:

wrk -t50 -c1000 -d360s 'https://esni-rev-proxy.npw:443' --timeout 15s
Изпълняване на тест за 6m @ https://esni-rev-proxy.npw:443
  50 нишки и 1000 връзки
  Статистика на нишките  Avg      Stdev      Max   +/- Stdev
    Латентност      1.77с     1.21с    7.20с   65.43%
    Req/Sec    13.78      8.84   140.00     83.70%
  206357 заявки за 6.00m, 6.08GB прочетени
Заявки/сек:    573.07
Прехвърляне/сек:     17.28MB

Натоварващото тестване, което проведохме, беше чисто качествено, за да сравним схемите с използване на ESNI обратен прокси и без него. Ние „наливаме“ трафик локално, за да изключим „шифровките“ в междинните компоненти.

Така, с поддръжка на ESNI и проксирането на upstream с HTTP, получихме около ~ 550 rps от един инстанс, като средното потребление на CPU/RAM на ESNI обратния прокси:

80% Употреба на CPU (4 vCPU, 4 GB RAM хостове, Linux)
130 MB Mem RSS

За сравнение, RPS за същия upstream nginx без терминализация на TLS (HTTP протокол) ~ 1100:

wrk -t50 -c1000 -d360s 'http://lb.npw:80' --timeout 15s
Изпълняване на тест за 6m @ http://lb.npw:80
  50 нишки и 1000 връзки
  Статистика на нишките  Avg      Stdev      Max   +/- Stdev
    Латентност      1.11с     2.30с    15.00с   90.94%
    Req/Sec    23.25      13.55   282.00     79.25%
  393093 заявки за 6.00m, 11.35GB прочетени
  Грешки в сокетите: свързване 0, четене 0, запис 0, тайм-аут 9555
  Отговори, различни от 2xx или 3xx: 8111
Заявки/сек:   1091.62
Прехвърляне/сек:     32.27MB

Присъствието на тайм-аутите показва, че има недостиг на ресурси (използвахме 4 vCPU, 4 GB RAM хостове, Linux), и всъщност потенциалният RPS е по-висок (сред цифрите достигнахме до 2700 RPS на по-мощни ресурси).

В заключение, ще отбележа, че технологията ESNI изглежда доста обещаваща. Още много въпроси остават отворени, например, въпросите за съхранението на публичния ESNI ключ в DNS и ротацията на ESNI ключовете – тези въпроси активно се обсъждат, а последната версия на проекта (в момента на написването) ESNI вече 7.

Източник: habr.com