🥇Коомдук веб-сайтыңызды ESNI менен кантип коргоого болот

Салам Хабр, менин атым Илья, мен Exness платформасында иштейм. Биз өнүмдү иштеп чыгуу топторубуз колдонгон негизги инфраструктура компоненттерин иштеп чыгып, ишке ашырабыз.

Бул макалада мен коомдук веб-сайттардын инфраструктурасында шифрленген SNI (ESNI) технологиясын киргизүү боюнча тажрыйбам менен бөлүшкүм келет.

Бул технологияны колдонуу коомдук веб-сайт менен иштөөдө коопсуздуктун деңгээлин жогорулатат жана Компания тарабынан кабыл алынган ички коопсуздук стандарттарына ылайык келет.

Биринчиден, мен технология стандартташтырылбаганын жана дагы эле долбоордо экенин белгилеп кетким келет, бирок CloudFlare жана Mozilla аны колдойт (жылы draft01). Бул бизге ушундай эксперимент жүргүзүүгө түрткү болду.

теориясынын бир үзүм

ESNI TLS кол алышуу "Кардар Hello" билдирүүсүндө SNI шифрлөөгө мүмкүндүк берген TLS 1.3 протоколунун кеңейтүүсү. Бул жерде Client Hello ESNI колдоосу менен кандай көрүнөт (кадимки SNIдин ордуна биз ESNI көрөбүз):

ESNI колдонуу үчүн сизге үч компонент керек:

DNS;
Кардарларды колдоо;
Сервер тарап колдоо.

DNS

Сиз эки DNS жазууларды кошуу керек - Aжана TXT (TXT жазуусу кардар SNI шифрлей ала турган ачык ачкычты камтыйт) - төмөндө караңыз. Мындан тышкары, колдоо болушу керек Пластилин (HTTPS аркылуу DNS), анткени жеткиликтүү кардарлар (төмөндө караңыз) DoH жок ESNI колдоосун иштетпейт. Бул логикалуу, анткени ESNI биз кирип жаткан ресурстун аталышын шифрлөө дегенди билдирет, башкача айтканда, UDP аркылуу DNSке кирүү мааниси жок. Мындан тышкары, пайдалануу DNSSEC бул сценарийде кэш уулануу чабуулдарынан коргоого мүмкүндүк берет.

Учурда жеткиликтүү бир нече DoH провайдерлери, алардын арасында:

CloudFlare мамлекеттер (Менин Браузеримди текшериңиз → Шифрленген SNI → Көбүрөөк билүү) алардын серверлери ESNI колдойт, башкача айтканда, DNSтеги CloudFlare серверлери үчүн бизде жок дегенде эки жазуу бар - 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": "Response from 2400:cb00:2049:1::a29f:209."
}

Ошентип, DNS көз карашынан алганда, биз DoH колдонушубуз керек (DNSSEC менен жакшыраак) жана эки жазууну кошушубуз керек.

Кардарларды колдоо

Биз браузерлер жөнүндө сөз болсо, анда учурда колдоо FireFoxто гана ишке ашырылат. бул Бул жерде FireFoxто ESNI жана DoH колдоосун кантип активдештирүү боюнча көрсөтмөлөр бар. Браузер конфигурациялангандан кийин, биз бул сыяктуу нерсени көрүшүбүз керек:

байланыш браузерди текшерүү үчүн.

Албетте, TLS 1.3 ESNI колдоо үчүн колдонулушу керек, анткени ESNI TLS 1.3 кеңейтүүсү болуп саналат.

ESNI колдоосу менен серверди сынап көрүү максатында, биз кардарды ишке киргиздик go, Бирок бул тууралуу кийинчерээк.

Сервер тарап колдоо

Учурда ESNI nginx/apache ж.б. сыяктуу веб-серверлер тарабынан колдоого алынбайт, анткени алар OpenSSL/BoringSSL аркылуу TLS менен иштешет, алар ESNI'ни расмий түрдө колдоого албайт.

Ошондуктан, биз өзүбүздүн алдыңкы компонентибизди (ESNI тескери прокси) түзүүнү чечтик, ал ESNI менен TLS 1.3 токтотууну жана ESNI колдоого албаган прокси HTTP(S) трафикти жогору агымга колдойт. Бул технологияны мурунтан эле бар инфраструктурада, негизги компоненттерди өзгөртпөстөн, башкача айтканда, ESNI колдобогон учурдагы веб-серверлерди колдонууга мүмкүндүк берет.

Тактык үчүн, бул жерде диаграмма болуп саналат:

Прокси TLS байланышын ESNIсиз токтотуу, ESNI жок кардарларды колдоо мүмкүнчүлүгү менен иштелип чыкканын белгилеймин. Ошондой эле, жогорку агым менен байланыш протоколу HTTP же HTTPS болушу мүмкүн, TLS версиясы 1.3төн төмөн (эгерде жогору агым 1.3 колдоого албаса). Бул схема максималдуу ийкемдүүлүктү берет.

ESNI колдоосун ишке ашыруу боюнча go биз карыз алганбыз CloudFlare. Мен дароо белгилеп кетким келет, ишке ашыруунун өзү анча маанилүү эмес, анткени ал стандарттык китепканага өзгөртүүлөрдү камтыйт. крипто/тлс ошондуктан "жамалоо" талап кылынат GOROOT чогулуштун алдында.

ESNI ачкычтарын түзүү үчүн биз колдонгон esnitool (Ошондой эле CloudFlare ойлоп тапкан). Бул ачкычтар SNI шифрлөө/дешифрлөө үчүн колдонулат.
Биз курулушту go 1.13 колдонуп сынап көрдүк Linux (Debian, Альп) жана MacOS.

операциялык өзгөчөлүктөрү жөнүндө бир нече сөз

ESNI тескери прокси Prometheus форматындагы көрсөткүчтөрдү камсыз кылат, мисалы, rps, агымдагы күтүү жана жооп коддору, ийгиликсиз/ийгиликтүү TLS кол алышуу жана TLS кол алышуу узактыгы. Бир караганда, бул прокси трафикти кантип башкарарын баалоо үчүн жетиштүү көрүндү.

Колдонуудан мурун биз жүктөмдү сыноодон өткөрдүк. Төмөндө жыйынтыктар:

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

Биз схеманы салыштыруу үчүн ESNI тескери прокси аркылуу жана ансыз гана сапаттык жүктөө тестин жүргүздүк. Аралык компоненттердеги «тоскоолдуктарды» жок кылуу үчүн биз трафикти локалдык түрдө «төктүк».

Ошентип, ESNI колдоосу жана HTTP'ден өйдө агымга прокси менен, биз ESNI тескери проксисинин орточо CPU/RAM керектөөсү менен бир инстанциядан ~550 rpps алдык:

80% CPU колдонулушу (4 vCPU, 4 ГБ оперативдик эс тутум хосттору, Linux)
130 МБ Mem RSS

Салыштыруу үчүн, TLS (HTTP протоколу) токтобогон бир эле nginx агымы үчүн RPS ~ 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 ГБ оперативдик эс тутум хостторун колдондук, Linux), жана чындыгында потенциалдуу RPS жогору (биз күчтүүрөөк ресурстар боюнча 2700 RPSке чейинки сандарды алдык).

Жыйынтыктап айтканда, мен белгилейм ESNI технологиясы абдан келечектүү көрүнөт. Дагы көптөгөн ачык суроолор бар, мисалы, ачык ESNI ачкычын DNSде сактоо жана ESNI ачкычтарын айлантуу маселелери - бул маселелер активдүү талкууланып жатат жана ESNI долбоорунун акыркы версиясы (жазуу учурунда) 7.

Source: www.habr.com