ESNI मार्फत तपाईंको सार्वजनिक वेबसाइट कसरी सुरक्षित गर्ने

नमस्ते हबर, मेरो नाम इल्या हो, म Exness मा प्लेटफर्म टोलीमा काम गर्छु। हामी हाम्रा उत्पादन विकास टोलीहरूले प्रयोग गर्ने आधारभूत पूर्वाधार घटकहरू विकास र कार्यान्वयन गर्छौं।

यस लेखमा, म सार्वजनिक वेबसाइटहरूको पूर्वाधारमा इन्क्रिप्टेड SNI (ESNI) प्रविधि लागू गर्ने मेरो अनुभव साझा गर्न चाहन्छु।

यस प्रविधिको प्रयोगले सार्वजनिक वेबसाइटसँग काम गर्दा सुरक्षाको स्तर बढाउनेछ र कम्पनीले अपनाएको आन्तरिक सुरक्षा मापदण्डहरूको पालना गर्नेछ।

सबैभन्दा पहिले, म यो कुरा औंल्याउन चाहन्छु कि यो प्रविधि मानकीकृत छैन र अझै मस्यौदामा छ, तर क्लाउडफ्लेयर र मोजिलाले पहिले नै यसलाई समर्थन गर्दछ (मा ड्राफ्ट ०१)। यही कुराले हामीलाई यस्तो प्रयोग गर्न प्रेरित गर्‍यो।

बिट सिद्धान्त

ESNIComment – TLS १.३ प्रोटोकलको एक्सटेन्सन हो जसले तपाईंलाई "क्लाइन्ट हेलो" TLS ह्यान्डशेक सन्देशमा SNI इन्क्रिप्ट गर्न अनुमति दिन्छ। 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 मा 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 मा ESNI र DoH समर्थन कसरी सक्रिय गर्ने भन्ने बारे निर्देशनहरू प्रदान गरिएको छ। ब्राउजर कन्फिगर गरिसकेपछि, हामीले यस्तो केहि देख्नुपर्छ:

लिङ्क ब्राउजर जाँच गर्न।

अवश्य पनि, ESNI लाई समर्थन गर्न TLS १.३ प्रयोग गर्नुपर्छ, किनकि ESNI TLS १.३ को विस्तार हो।

ESNI समर्थनको साथ ब्याकएन्ड परीक्षण गर्ने उद्देश्यले, हामीले एउटा क्लाइन्ट लागू गर्यौं go, तर त्यसबारे पछि थप कुरा गरौंला।

सर्भर साइड समर्थन

हाल ESNI लाई nginx/apache आदि जस्ता वेब सर्भरहरूले समर्थन गर्दैनन्, किनकि तिनीहरू OpenSSL/BoringSSL मार्फत TLS सँग काम गर्छन्, जसले आधिकारिक रूपमा ESNI लाई समर्थन गर्दैनन्।

त्यसैले हामीले हाम्रो आफ्नै फ्रन्ट-एन्ड कम्पोनेन्ट (ESNI रिभर्स प्रोक्सी) सिर्जना गर्ने निर्णय गर्यौं, जसले ESNI सँग TLS 1.3 टर्मिनेशनलाई समर्थन गर्नेछ र HTTP(S) ट्राफिकलाई अपस्ट्रीममा प्रोक्सी गर्नेछ, जसले ESNI लाई समर्थन गर्दैन। यसले मुख्य कम्पोनेन्टहरू परिवर्तन नगरी पहिले नै अवस्थित पूर्वाधारमा प्रविधि प्रयोग गर्न अनुमति दिन्छ - अर्थात्, ESNI लाई समर्थन नगर्ने हालको वेब सर्भरहरू प्रयोग गरेर। 

स्पष्टताको लागि, यहाँ एउटा रेखाचित्र छ:

म यो कुरा याद गर्न चाहन्छु कि प्रोक्सी ESNI बिना TLS जडान समाप्त गर्ने क्षमताको साथ डिजाइन गरिएको थियो, ESNI बिना क्लाइन्टहरूलाई समर्थन गर्न। साथै, अपस्ट्रिमसँग सञ्चार गर्ने प्रोटोकल HTTP वा HTTPS हुन सक्छ जसको TLS संस्करण १.३ भन्दा कम छ (यदि अपस्ट्रिमले १.३ लाई समर्थन गर्दैन भने)। यो योजनाले अधिकतम लचिलोपन प्रदान गर्दछ।

ESNI समर्थनको कार्यान्वयन go हामीले बाट सापटी लिएका छौं CloudFlare। म तुरुन्तै ध्यान दिनेछु कि कार्यान्वयन आफैंमा एकदमै सामान्य छैन, किनकि यसले मानक पुस्तकालयमा परिवर्तनहरू संकेत गर्दछ। crypto/tls र त्यसैले "प्याचिङ" आवश्यक छ GOROOT सभा गर्नु अघि।

ESNI कुञ्जीहरू उत्पन्न गर्न हामीले प्रयोग गर्यौं एस्निटुल (क्लाउडफ्लेयर सिर्जना पनि)। यी कुञ्जीहरू SNI इन्क्रिप्ट/डिक्रिप्ट गर्न प्रयोग गरिन्छ।
हामीले go १.१३ अन प्रयोग गरेर बिल्डको परीक्षण गर्यौं। Linux (Debian, अल्पाइन) र MacOS। 

सञ्चालन सुविधाहरूको बारेमा केहि शब्दहरू

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 सँग अपस्ट्रीम प्रोक्सीको साथ, हामीले एक उदाहरणबाट लगभग ~५५० rps पायौं, ESNI रिभर्स प्रोक्सीको औसत CPU/RAM खपतको साथ:

• ८०% CPU उपयोग (४ vCPU, ४ GB RAM होस्टहरू, Linux)
• १३० एमबी मेम आरएसएस

तुलनाको लागि, TLS टर्मिनेशन (HTTP प्रोटोकल) बिना उही nginx अपस्ट्रीमको लागि RPS ~ ११०० छ:

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 

टाइमआउटको उपस्थितिले स्रोतहरूको अभाव भएको संकेत गर्छ (हामीले ४ वटा vCPU, ४ GB RAM होस्टहरू प्रयोग गर्यौं, Linux), र वास्तवमा सम्भावित RPS उच्च छ (हामीले अधिक शक्तिशाली स्रोतहरूमा २७०० RPS सम्मको तथ्याङ्क प्राप्त गर्यौं)।

निष्कर्षमा, म यो कुरा याद गर्न चाहन्छु कि ESNI प्रविधि एकदमै आशाजनक देखिन्छ। अझै पनि धेरै खुला प्रश्नहरू छन्, उदाहरणका लागि, DNS मा सार्वजनिक ESNI कुञ्जी भण्डारण गर्ने र ESNI कुञ्जीहरू घुमाउने मुद्दाहरू - यी मुद्दाहरू सक्रिय रूपमा छलफल गरिएका छन्, र ESNI को मस्यौदाको पछिल्लो संस्करण (लेखनको समयमा) पहिले नै छ। 7.

स्रोत: www.habr.com