Habari Habr, jina langu ni Ilya, ninafanya kazi katika timu ya jukwaa huko Exness. Tunatengeneza na kutekeleza vipengele muhimu vya miundombinu ambavyo timu zetu za utengenezaji wa bidhaa hutumia.
Katika makala haya, ningependa kushiriki uzoefu wangu wa kutekeleza teknolojia iliyosimbwa ya SNI (ESNI) katika miundombinu ya tovuti za umma.
Matumizi ya teknolojia hii yataongeza kiwango cha usalama wakati wa kufanya kazi na tovuti ya umma na kuzingatia viwango vya usalama vya ndani vilivyopitishwa na Kampuni.
Kwanza kabisa, ningependa kusema kwamba teknolojia haijasawazishwa na bado iko kwenye rasimu, lakini CloudFlare na Mozilla tayari wanaiunga mkono (katika ) Hii ilituchochea kwa jaribio kama hilo.
Nadharia kidogo
ESNI ni kiendelezi kwa itifaki ya TLS 1.3 inayoruhusu usimbaji fiche wa SNI katika ujumbe wa TLS wa kupeana mkono "Hujambo Mteja". Hivi ndivyo Client Hello inavyoonekana kwa usaidizi wa ESNI (badala ya SNI ya kawaida tunaona ESNI):
Ili kutumia ESNI, unahitaji vipengele vitatu:
- DNS;
- Msaada wa mteja;
- Usaidizi wa upande wa seva.
DNS
Unahitaji kuongeza rekodi mbili za DNS - ANa Txt (Rekodi ya TXT ina ufunguo wa umma ambao mteja anaweza kusimba SNI kwa njia fiche) - tazama hapa chini. Kwa kuongeza, kuna lazima iwe na msaada DoH (DNS kupitia HTTPS) kwa sababu wateja wanaopatikana (tazama hapa chini) hawawashi usaidizi wa ESNI bila DoH. Hii ni ya kimantiki, kwani ESNI inamaanisha usimbuaji fiche wa jina la rasilimali tunayopata, yaani, haina mantiki kupata DNS kupitia UDP. Aidha, matumizi inakuwezesha kulinda dhidi ya mashambulizi ya sumu ya cache katika hali hii.
Inapatikana kwa sasa , kati yao:
Wingu (Angalia Kivinjari Changu β SNI Iliyosimbwa kwa Njia Fiche β Jifunze Zaidi) kwamba seva zao tayari zinatumia ESNI, yaani, kwa seva za CloudFlare katika DNS tuna angalau rekodi mbili - A na TXT. Katika mfano hapa chini tunauliza Google DNS (juu ya HTTPS):
Π kuingia:
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 rekodi, ombi hutolewa kulingana na kiolezo _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."
}Kwa hivyo, kwa mtazamo wa DNS, tunapaswa kutumia DoH (ikiwezekana kwa DNSSEC) na kuongeza maingizo mawili.
Usaidizi wa Wateja
Ikiwa tunazungumza juu ya vivinjari, basi kwa sasa . Haya hapa ni maagizo ya jinsi ya kuwezesha usaidizi wa ESNI na DoH katika Firefox. Baada ya kivinjari kusanidiwa, tunapaswa kuona kitu kama hiki:
kuangalia kivinjari.
Bila shaka, TLS 1.3 lazima itumike kusaidia ESNI, kwa kuwa ESNI ni kiendelezi kwa TLS 1.3.
Kwa madhumuni ya kujaribu mazingira ya nyuma kwa usaidizi wa ESNI, tulitekeleza mteja kwenye go, Lakini zaidi juu ya hilo baadaye.
Usaidizi wa upande wa seva
Kwa sasa, ESNI haitumiki na seva za wavuti kama vile nginx/apache, n.k., kwa kuwa zinafanya kazi na TLS kupitia OpenSSL/BoringSSL, ambazo hazitumii ESNI rasmi.
Kwa hivyo, tuliamua kuunda kijenzi chetu chetu cha mwisho cha mbele (ESNI reverse proksi), ambayo inaweza kusaidia kusitishwa kwa TLS 1.3 na ESNI na trafiki ya proksi ya HTTP(S) hadi juu, ambayo haitumii ESNI. Hii inaruhusu teknolojia kutumika katika miundombinu iliyopo tayari, bila kubadilisha vipengele vikuu - yaani, kutumia seva za sasa za mtandao ambazo haziunga mkono ESNI.
Kwa uwazi, hapa kuna mchoro:
Ninakumbuka kuwa proksi iliundwa ikiwa na uwezo wa kuzima muunganisho wa TLS bila ESNI, ili kusaidia wateja bila ESNI. Pia, itifaki ya mawasiliano yenye mkondo wa juu inaweza kuwa HTTP au HTTPS yenye toleo la TLS chini ya 1.3 (ikiwa mkondo wa juu hauauni 1.3). Mpango huu unatoa kubadilika kwa kiwango cha juu.
Utekelezaji wa msaada wa ESNI kwenye go tulikopa kutoka . Ningependa kutambua mara moja kuwa utekelezaji wenyewe sio mdogo, kwani unajumuisha mabadiliko katika maktaba ya kawaida. crypto/tls na kwa hivyo inahitaji "kubandika" GOROOT kabla ya mkusanyiko.
Ili kutengeneza funguo za ESNI tulitumia (pia mwanzilishi wa CloudFlare). Vifunguo hivi vinatumika kwa usimbaji/usimbuaji wa SNI.
Tulijaribu muundo kwa kutumia go 1.13 kwenye Linux (Debian, Alpine) na MacOS.
Maneno machache kuhusu vipengele vya uendeshaji
Seva mbadala ya ESNI hutoa vipimo katika umbizo la Prometheus, kama vile rps, misimbo ya kusubiri na ya majibu juu ya mkondo, kupeana mikono kwa TLS iliyoshindwa/imefaulu na muda wa TLS wa kupeana mkono. Kwa mtazamo wa kwanza, hii ilionekana kutosha kutathmini jinsi proksi inavyoshughulikia trafiki.
Pia tulifanya majaribio ya upakiaji kabla ya matumizi. Matokeo hapa chini:
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 Tulifanya majaribio ya ubora wa upakiaji ili kulinganisha mpango kwa kutumia seva mbadala ya ESNI na bila. "Tulimimina" trafiki ndani ya nchi ili kuondoa "kuingilia" katika vipengele vya kati.
Kwa hivyo, kwa usaidizi wa ESNI na uwakilishi wa kupanda juu kutoka kwa HTTP, tulipata takriban ~ 550 rps kutoka kwa mfano mmoja, na matumizi ya wastani ya CPU/RAM ya proksi ya ESNI ya kurudi nyuma:
- 80% ya Matumizi ya CPU (4 vCPU, vipangishi vya RAM vya GB 4, Linux)
- 130 MB Mem RSS
Kwa kulinganisha, RPS kwa nginx sawa juu mkondo bila TLS (HTTP itifaki) kusitisha ni ~ 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 Uwepo wa muda unaonyesha kuwa kuna ukosefu wa rasilimali (tulitumia vCPU 4, majeshi ya RAM ya GB 4, Linux), na kwa kweli RPS inayowezekana ni ya juu (tulipokea takwimu za hadi 2700 RPS kwenye rasilimali zenye nguvu zaidi).
Kwa kumalizia, naona kwamba teknolojia ya ESNI inaonekana kuahidi sana. Bado kuna maswali mengi ya wazi, kwa mfano, masuala ya kuhifadhi ufunguo wa ESNI wa umma katika DNS na funguo za ESNI zinazozunguka - masuala haya yanajadiliwa kikamilifu, na toleo la hivi karibuni la rasimu ya ESNI (wakati wa kuandika) tayari iko. .
Chanzo: mapenzi.com