ESNIతో మీ పబ్లిక్ వెబ్‌సైట్‌ను ఎలా రక్షించుకోవాలి

హలో హబ్ర్, నా పేరు ఇలియా, నేను ఎక్స్‌నెస్‌లో ప్లాట్‌ఫారమ్ బృందంలో పని చేస్తున్నాను. మా ఉత్పత్తి అభివృద్ధి బృందాలు ఉపయోగించే ప్రధాన మౌలిక సదుపాయాల భాగాలను మేము అభివృద్ధి చేస్తాము మరియు అమలు చేస్తాము.

ఈ ఆర్టికల్‌లో, పబ్లిక్ వెబ్‌సైట్‌ల ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ఎన్‌క్రిప్టెడ్ SNI (ESNI) టెక్నాలజీని అమలు చేయడంలో నా అనుభవాన్ని పంచుకోవాలనుకుంటున్నాను.

ఈ సాంకేతికత యొక్క ఉపయోగం పబ్లిక్ వెబ్‌సైట్‌తో పనిచేసేటప్పుడు భద్రతా స్థాయిని పెంచుతుంది మరియు కంపెనీ ఆమోదించిన అంతర్గత భద్రతా ప్రమాణాలకు అనుగుణంగా ఉంటుంది.

అన్నింటిలో మొదటిది, సాంకేతికత ప్రమాణీకరించబడలేదు మరియు ఇప్పటికీ డ్రాఫ్ట్‌లో ఉందని నేను ఎత్తి చూపాలనుకుంటున్నాను, అయితే CloudFlare మరియు Mozilla ఇప్పటికే దీనికి మద్దతు ఇస్తున్నాయి (లో చిత్తుప్రతి 01) ఇది అటువంటి ప్రయోగానికి మమ్మల్ని ప్రేరేపించింది.

సిద్ధాంతం యొక్క బిట్

ESNI TLS హ్యాండ్‌షేక్ "క్లయింట్ హలో" సందేశంలో SNI గుప్తీకరణను అనుమతించే TLS 1.3 ప్రోటోకాల్‌కు పొడిగింపు. ESNI మద్దతుతో క్లయింట్ హలో ఎలా ఉంటుందో ఇక్కడ ఉంది (సాధారణ SNIకి బదులుగా మనం ESNIని చూస్తాము):

 ESNIని ఉపయోగించడానికి, మీకు మూడు భాగాలు అవసరం:

• DNS; 
• క్లయింట్ మద్దతు;
• సర్వర్ వైపు మద్దతు.

DNS

మీరు రెండు DNS రికార్డులను జోడించాలి - Aమరియు TXT (TXT రికార్డ్‌లో క్లయింట్ SNIని ఎన్‌క్రిప్ట్ చేయగల పబ్లిక్ కీ ఉంది) - క్రింద చూడండి. అదనంగా, మద్దతు ఉండాలి DoH (HTTPS ద్వారా DNS) ఎందుకంటే అందుబాటులో ఉన్న క్లయింట్లు (క్రింద చూడండి) DoH లేకుండా ESNI మద్దతును ప్రారంభించవు. ఇది తార్కికం, ఎందుకంటే ESNI అనేది మనం యాక్సెస్ చేస్తున్న వనరు పేరు యొక్క ఎన్‌క్రిప్షన్‌ను సూచిస్తుంది, అంటే UDP ద్వారా DNSని యాక్సెస్ చేయడంలో అర్థం లేదు. అదనంగా, ఉపయోగం DNSSEC ఈ దృష్టాంతంలో కాష్ పాయిజనింగ్ దాడుల నుండి రక్షించడానికి మిమ్మల్ని అనుమతిస్తుంది.

ప్రస్తుతం అందుబాటులో అనేక DoH ప్రొవైడర్లు, వారందరిలో:

• CloudFlare
• opendns
• గూగుల్

CloudFlare రాష్ట్రాలు (నా బ్రౌజర్‌ని తనిఖీ చేయండి → ఎన్‌క్రిప్టెడ్ SNI → మరింత తెలుసుకోండి) వారి సర్వర్‌లు ఇప్పటికే ESNIకి మద్దతు ఇస్తున్నాయి, అంటే, 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": "Response from 2400:cb00:2049:1::a29f:209."
}

కాబట్టి, DNS దృక్కోణం నుండి, మేము DoH (ప్రాధాన్యంగా DNSSECతో) ఉపయోగించాలి మరియు రెండు ఎంట్రీలను జోడించాలి. 

వినియోగదారుని మద్దతు

మేము బ్రౌజర్‌ల గురించి మాట్లాడుతుంటే, ప్రస్తుతానికి మద్దతు FireFoxలో మాత్రమే అమలు చేయబడుతుంది. ఇది FireFoxలో 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 లేకుండా క్లయింట్‌లకు మద్దతు ఇవ్వడానికి, ESNI లేకుండా TLS కనెక్షన్‌ని ముగించే సామర్థ్యంతో ప్రాక్సీ రూపొందించబడిందని నేను గమనించాను. అలాగే, అప్‌స్ట్రీమ్‌తో కమ్యూనికేషన్ ప్రోటోకాల్ 1.3 కంటే తక్కువ TLS వెర్షన్‌తో HTTP లేదా HTTPS కావచ్చు (అప్‌స్ట్రీమ్ 1.3కి మద్దతు ఇవ్వకపోతే). ఈ పథకం గరిష్ట సౌలభ్యాన్ని ఇస్తుంది.

ESNI మద్దతు అమలు go మేము నుండి అప్పు తీసుకున్నాము CloudFlare. ప్రామాణిక లైబ్రరీలో మార్పులను కలిగి ఉన్నందున, అమలు చేయడం చాలా చిన్నవిషయం కాదని నేను వెంటనే గమనించాలనుకుంటున్నాను crypto/tls అందువలన "పాచింగ్" అవసరం గోరూట్ అసెంబ్లీ ముందు.

మేము ఉపయోగించిన ESNI కీలను రూపొందించడానికి ఎస్నిటూల్ (క్లౌడ్‌ఫ్లేర్ యొక్క ఆలోచన కూడా). ఈ కీలు 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 MB మెమ్ 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 GB RAM హోస్ట్‌లు, Linuxని ఉపయోగించాము), మరియు వాస్తవానికి సంభావ్య RPS ఎక్కువగా ఉంది (మేము మరింత శక్తివంతమైన వనరులపై 2700 RPS వరకు గణాంకాలను అందుకున్నాము).

ముగింపులో, నేను గమనించాను ESNI సాంకేతికత చాలా ఆశాజనకంగా కనిపిస్తోంది. ఇంకా చాలా ఓపెన్ ప్రశ్నలు ఉన్నాయి, ఉదాహరణకు, DNSలో పబ్లిక్ ESNI కీని నిల్వ చేయడం మరియు ESNI కీలను తిప్పడం వంటి సమస్యలు - ఈ సమస్యలు చురుకుగా చర్చించబడుతున్నాయి మరియు ESNI డ్రాఫ్ట్ యొక్క తాజా వెర్షన్ (వ్రాసే సమయంలో) ఇప్పటికే ఉంది 7.

మూలం: www.habr.com