તમારી સાર્વજનિક વેબસાઇટને ESNI વડે કેવી રીતે સુરક્ષિત કરવી

હેલો હેબ્ર, મારું નામ ઇલ્યા છે, હું Exness પર પ્લેટફોર્મ ટીમમાં કામ કરું છું. અમે અમારી પ્રોડક્ટ ડેવલપમેન્ટ ટીમો ઉપયોગ કરે છે તેવા કોર ઇન્ફ્રાસ્ટ્રક્ચર ઘટકોનો વિકાસ અને અમલ કરીએ છીએ.

આ લેખમાં, હું સાર્વજનિક વેબસાઇટ્સના ઇન્ફ્રાસ્ટ્રક્ચરમાં એન્ક્રિપ્ટેડ SNI (ESNI) ટેક્નોલોજીનો અમલ કરવાનો મારો અનુભવ શેર કરવા માંગુ છું.

આ ટેક્નોલોજીનો ઉપયોગ સાર્વજનિક વેબસાઇટ સાથે કામ કરતી વખતે સુરક્ષાનું સ્તર વધારશે અને કંપની દ્વારા અપનાવવામાં આવેલા આંતરિક સુરક્ષા ધોરણોનું પાલન કરશે.

સૌ પ્રથમ, હું એ નિર્દેશ કરવા માંગુ છું કે ટેક્નોલોજી પ્રમાણિત નથી અને હજુ પણ ડ્રાફ્ટમાં છે, પરંતુ CloudFlare અને Mozilla પહેલેથી જ તેને સમર્થન આપે છે (માં ડ્રાફ્ટ01). આનાથી અમને આવા પ્રયોગ માટે પ્રેરણા મળી.

સિદ્ધાંત એક બીટ

ESNI TLS 1.3 પ્રોટોકોલનું વિસ્તરણ છે જે TLS હેન્ડશેક "ક્લાયન્ટ હેલો" સંદેશમાં SNI એન્ક્રિપ્શનને મંજૂરી આપે છે. ESNI સપોર્ટ સાથે ક્લાઈન્ટ હેલો કેવો દેખાય છે તે અહીં છે (સામાન્ય SNIને બદલે આપણે ESNI જોઈએ છીએ):

 ESNI નો ઉપયોગ કરવા માટે, તમારે ત્રણ ઘટકોની જરૂર છે:

• DNS; 
• ક્લાયંટ સપોર્ટ;
• સર્વર બાજુ આધાર.

DNS

તમારે બે DNS રેકોર્ડ ઉમેરવાની જરૂર છે - Aઅને TXT (TXT રેકોર્ડમાં સાર્વજનિક કી છે જેની સાથે ક્લાયંટ SNI એન્ક્રિપ્ટ કરી શકે છે) - નીચે જુઓ. વધુમાં, ત્યાં આધાર હોવો જોઈએ DoH (HTTPS પર DNS) કારણ કે ઉપલબ્ધ ક્લાયન્ટ્સ (નીચે જુઓ) DoH વગર ESNI સપોર્ટને સક્ષમ કરતા નથી. આ તાર્કિક છે, કારણ કે ESNI એ સંસાધનના નામનું એન્ક્રિપ્શન સૂચવે છે જે અમે ઍક્સેસ કરી રહ્યા છીએ, એટલે કે, UDP પર DNS ઍક્સેસ કરવાનો કોઈ અર્થ નથી. વધુમાં, ઉપયોગ DNSSEC તમને આ દૃશ્યમાં કેશ ઝેરી હુમલાઓ સામે રક્ષણ કરવાની મંજૂરી આપે છે.

હાલમાં ઉપલબ્ધ છે કેટલાક DoH પ્રદાતાઓ, તેમની વચ્ચે:

• મેઘફ્લેર
• OpenDNS
• Google

મેઘફ્લેર જાહેર કરે છે (ચેક માય બ્રાઉઝર → એનક્રિપ્ટેડ 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 સાથે) નો ઉપયોગ કરવો જોઈએ અને બે એન્ટ્રી ઉમેરવી જોઈએ. 

ગ્રાહક સેવા

જો આપણે બ્રાઉઝર્સ વિશે વાત કરી રહ્યા છીએ, તો આ ક્ષણે સપોર્ટ ફક્ત ફાયરફોક્સમાં જ લાગુ કરવામાં આવે છે. તે ફાયરફોક્સમાં ESNI અને DoH સપોર્ટને કેવી રીતે સક્રિય કરવું તે અંગેની સૂચનાઓ અહીં છે. બ્રાઉઝર રૂપરેખાંકિત થયા પછી, આપણે આના જેવું કંઈક જોવું જોઈએ:

કડી બ્રાઉઝર તપાસવા માટે.

અલબત્ત, ESNI ને ટેકો આપવા માટે TLS 1.3 નો ઉપયોગ કરવો આવશ્યક છે, કારણ કે ESNI એ TLS 1.3નું વિસ્તરણ છે.

ESNI સપોર્ટ સાથે બેકએન્ડને ચકાસવાના હેતુ માટે, અમે ક્લાયન્ટને ચાલુ કર્યું છે go, પરંતુ તેના પર પછીથી વધુ.

સર્વર બાજુ આધાર

હાલમાં, ESNI ને nginx/apache, વગેરે જેવા વેબ સર્વર્સ દ્વારા સમર્થન આપવામાં આવતું નથી, કારણ કે તેઓ TLS સાથે OpenSSL/BoringSSL દ્વારા કામ કરે છે, જે ESNI ને સત્તાવાર રીતે સમર્થન આપતા નથી.

તેથી, અમે અમારું પોતાનું ફ્રન્ટ-એન્ડ કમ્પોનન્ટ (ESNI રિવર્સ પ્રોક્સી) બનાવવાનું નક્કી કર્યું છે, જે ESNI સાથે TLS 1.3 ટર્મિનેશન અને અપસ્ટ્રીમમાં પ્રોક્સી HTTP(S) ટ્રાફિકને સપોર્ટ કરશે, જે ESNI ને સપોર્ટ કરતું નથી. આ ટેક્નોલોજીને પહેલાથી અસ્તિત્વમાં રહેલા ઈન્ફ્રાસ્ટ્રક્ચરમાં, મુખ્ય ઘટકોને બદલ્યા વિના ઉપયોગમાં લેવાની મંજૂરી આપે છે - એટલે કે, વર્તમાન વેબ સર્વર્સનો ઉપયોગ કરીને જે ESNI ને સપોર્ટ કરતા નથી. 

સ્પષ્ટતા માટે, અહીં એક આકૃતિ છે:

હું નોંધું છું કે પ્રોક્સીને ESNI વગર TLS કનેક્શનને સમાપ્ત કરવાની ક્ષમતા સાથે ડિઝાઇન કરવામાં આવી હતી, જેથી ESNI વગરના ક્લાયંટને સપોર્ટ કરી શકાય. ઉપરાંત, અપસ્ટ્રીમ સાથેનો કોમ્યુનિકેશન પ્રોટોકોલ 1.3 કરતા ઓછા TLS વર્ઝન સાથે HTTP અથવા HTTPS હોઈ શકે છે (જો અપસ્ટ્રીમ 1.3ને સપોર્ટ કરતું નથી). આ યોજના મહત્તમ સુગમતા આપે છે.

પર ESNI સપોર્ટનો અમલ go અમે પાસેથી ઉધાર લીધેલ છે મેઘફ્લેર. હું તરત જ નોંધવા માંગુ છું કે અમલીકરણ પોતે જ તદ્દન બિન-તુચ્છ છે, કારણ કે તેમાં પ્રમાણભૂત લાઇબ્રેરીમાં ફેરફારો શામેલ છે ક્રિપ્ટો/tls અને તેથી "પેચિંગ" ની જરૂર છે ગરોટ એસેમ્બલી પહેલાં.

ESNI કી જનરેટ કરવા માટે અમે ઉપયોગ કર્યો હતો esnitool (ક્લાઉડફ્લેરનું પણ મગજની ઉપજ છે). આ કીનો ઉપયોગ SNI એન્ક્રિપ્શન/ડિક્રિપ્શન માટે થાય છે.
અમે Linux (Debian, Alpine) અને MacOS પર ગો 1.13 નો ઉપયોગ કરીને બિલ્ડનું પરીક્ષણ કર્યું. 

ઓપરેશનલ સુવિધાઓ વિશે થોડાક શબ્દો

ESNI રિવર્સ પ્રોક્સી પ્રોમિથિયસ ફોર્મેટમાં મેટ્રિક્સ પ્રદાન કરે છે, જેમ કે 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 rps મળ્યા છે:

• 80% CPU વપરાશ (4 vCPU, 4 GB RAM હોસ્ટ, Linux)
• 130 એમબી મેમ આરએસએસ

સરખામણી માટે, 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 vCPUs, 4 GB RAM હોસ્ટ્સ, Linux નો ઉપયોગ કર્યો છે), અને હકીકતમાં સંભવિત RPS વધારે છે (અમે વધુ શક્તિશાળી સંસાધનો પર 2700 RPS સુધીના આંકડા પ્રાપ્ત કર્યા છે).

નિષ્કર્ષમાં, હું નોંધું છું કે ESNI ટેકનોલોજી તદ્દન આશાસ્પદ લાગે છે. હજી પણ ઘણા ખુલ્લા પ્રશ્નો છે, ઉદાહરણ તરીકે, DNS માં સાર્વજનિક ESNI કીને સંગ્રહિત કરવા અને ESNI કીને ફેરવવાના મુદ્દાઓ - આ મુદ્દાઓ પર સક્રિયપણે ચર્ચા કરવામાં આવી રહી છે, અને ESNI ડ્રાફ્ટનું નવીનતમ સંસ્કરણ (લેખન સમયે) પહેલેથી જ છે. 7.

સોર્સ: www.habr.com