Salam Habr, mənim adım İlya, mən Exness-də platforma komandasında işləyirəm. Biz məhsul inkişaf qruplarımızın istifadə etdiyi əsas infrastruktur komponentlərini hazırlayır və həyata keçiririk.
Bu yazıda mən ictimai veb-saytların infrastrukturunda şifrələnmiş SNI (ESNI) texnologiyasının tətbiqi ilə bağlı təcrübəmi bölüşmək istərdim.
Bu texnologiyadan istifadə ictimai internet saytı ilə işləyərkən təhlükəsizlik səviyyəsini artıracaq və Şirkət tərəfindən qəbul edilmiş daxili təhlükəsizlik standartlarına uyğun olacaq.
Əvvəla, qeyd etmək istərdim ki, texnologiya standartlaşdırılmayıb və hələ də layihədədir, lakin CloudFlare və Mozilla artıq onu dəstəkləyir (in ). Bu, bizi belə bir təcrübəyə həvəsləndirdi.
Bir az nəzəriyyə
ESNI TLS əl sıxma "Müştəri Salam" mesajında SNI şifrələməsinə imkan verən TLS 1.3 protokolunun uzantısıdır. Client Hello ESNI dəstəyi ilə necə görünür (adi SNI əvəzinə ESNI görürük):
ESNI-dən istifadə etmək üçün sizə üç komponent lazımdır:
- DNS;
- Müştəri dəstəyi;
- Server tərəfi dəstəyi.
DNS
İki DNS qeydi əlavə etməlisiniz - AVə TXT (TXT qeydində müştərinin SNI-ni şifrələyə biləcəyi açıq açar var) - aşağıya baxın. Bundan əlavə, dəstək olmalıdır DOH (HTTPS üzərindən DNS), çünki mövcud müştərilər (aşağıya bax) DoH olmadan ESNI dəstəyini aktivləşdirmir. Bu məntiqlidir, çünki ESNI daxil olduğumuz resursun adının şifrələnməsini nəzərdə tutur, yəni UDP üzərindən DNS-ə daxil olmağın mənası yoxdur. Üstəlik, istifadə bu ssenaridə cache zəhərlənmə hücumlarından qorunmağa imkan verir.
Hazırda mövcuddur , onların arasında:
CloudFlare (Brauzerimi yoxlayın → Şifrələnmiş SNI → Ətraflı öyrənin) onların serverləri artıq ESNI-ni dəstəkləyir, yəni DNS-də CloudFlare serverləri üçün ən azı iki qeydimiz var - A və TXT. Aşağıdakı nümunədə biz Google DNS (HTTPS üzərindən) sorğusu edirik:
А giriş:
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 qeyd, sorğu şablona uyğun olaraq yaradılır _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."
}Beləliklə, DNS baxımından biz DoH (tercihen DNSSEC ilə) istifadə etməli və iki giriş əlavə etməliyik.
Müştəri dəstəyi
Brauzerlərdən danışırıqsa, bu anda . Burada FireFox-da ESNI və DoH dəstəyini necə aktivləşdirmək barədə təlimatlar verilmişdir. Brauzer konfiqurasiya edildikdən sonra belə bir şey görməliyik:
brauzeri yoxlamaq üçün.
Əlbəttə ki, ESNI-ni dəstəkləmək üçün TLS 1.3 istifadə edilməlidir, çünki ESNI TLS 1.3-ün uzantısıdır.
ESNI dəstəyi ilə arxa planı sınaqdan keçirmək üçün biz müştərini tətbiq etdik go, Amma bu haqda daha sonra.
Server tərəfi dəstəyi
Hal-hazırda ESNI nginx/apache və s. kimi veb serverlər tərəfindən dəstəklənmir, çünki onlar ESNI-ni rəsmi olaraq dəstəkləməyən OpenSSL/BoringSSL vasitəsilə TLS ilə işləyirlər.
Buna görə də biz TLS 1.3-ün ESNI ilə dayandırılmasını və ESNI-ni dəstəkləməyən yuxarı axın üçün proxy HTTP(S) trafikini dəstəkləyəcək öz qabaqcıl komponentimizi (ESNI tərs proxy) yaratmağa qərar verdik. Bu, texnologiyanın əsas komponentləri dəyişdirmədən, yəni ESNI-ni dəstəkləməyən cari veb serverlərdən istifadə etmədən, artıq mövcud olan infrastrukturda istifadə etməyə imkan verir.
Aydınlıq üçün burada bir diaqram var:
Qeyd edim ki, proksi ESNI olmadan TLS bağlantısını dayandırmaq, ESNI olmadan müştəriləri dəstəkləmək imkanı ilə hazırlanmışdır. Həmçinin, yuxarı axını ilə rabitə protokolu HTTP və ya 1.3-dən aşağı TLS versiyası ilə HTTPS ola bilər (əgər yuxarı axın 1.3-ü dəstəkləmirsə). Bu sxem maksimum rahatlıq verir.
ESNI dəstəyinin həyata keçirilməsi go dan borc almışıq . Dərhal qeyd etmək istərdim ki, tətbiqin özü olduqca qeyri-ciddidir, çünki standart kitabxanada dəyişiklikləri nəzərdə tutur. kripto/TL və buna görə də "yamaq" tələb olunur GOROOT montajdan əvvəl.
ESNI açarlarını yaratmaq üçün istifadə etdik (həmçinin CloudFlare-nin ideyasıdır). Bu açarlar SNI şifrələməsi/şifrəsinin açılması üçün istifadə olunur.
Linux (Debian, Alpine) və MacOS-da go 1.13 istifadə edərək quruluşu sınaqdan keçirdik.
Əməliyyat xüsusiyyətləri haqqında bir neçə kəlmə
ESNI əks proksi Prometheus formatında rps, yuxarı gecikmə və cavab kodları, uğursuz/uğurlu TLS əl sıxışmaları və TLS əl sıxma müddəti kimi ölçüləri təmin edir. İlk baxışdan bu, proksinin trafiki necə idarə etdiyini qiymətləndirmək üçün yetərli görünürdü.
İstifadə etməzdən əvvəl yük testini də həyata keçirdik. Aşağıdakı nəticələr:
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 reverse proxy-dən istifadə edərək və olmadan sxemi müqayisə etmək üçün sırf keyfiyyətli yük testi həyata keçirdik. Aralıq komponentlərdəki "müdaxilələri" aradan qaldırmaq üçün trafiki yerli olaraq "tökdük".
Beləliklə, ESNI dəstəyi və HTTP-dən yuxarı axın üçün proksi ilə biz ESNI əks proxy-nin orta CPU/RAM istehlakı ilə bir instansiyadan təxminən ~550 rps əldə etdik:
- 80% CPU İstifadəsi (4 vCPU, 4 GB RAM hostları, Linux)
- 130 MB Mem RSS
Müqayisə üçün, TLS (HTTP protokolu) dayandırılmadan eyni nginx upstream üçün RPS ~ 1100-dür:
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 Taym-autların olması resursların çatışmazlığından xəbər verir (biz 4 vCPU, 4 GB RAM host, Linux istifadə etdik) və əslində potensial RPS daha yüksəkdir (daha güclü resurslarda 2700 RPS-ə qədər rəqəmlər aldıq).
Sonda qeyd edirəm ESNI texnologiyası olduqca perspektivli görünür. Hələ bir çox açıq suallar var, məsələn, ictimai ESNI açarının DNS-də saxlanması və ESNI açarlarının fırlanması məsələləri - bu məsələlər aktiv şəkildə müzakirə olunur və ESNI layihəsinin son versiyası (yazı zamanı) artıq .
Mənbə: www.habr.com