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

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

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

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

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

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

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 प्रदायकहरू, उनीहरु मध्ये:

• 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 सँग) र दुई प्रविष्टिहरू थप्नुहोस्। 

ग्राहक समर्थन

यदि हामी ब्राउजरहरूको बारेमा कुरा गर्दै हुनुहुन्छ भने, त्यस समयमा समर्थन फायरफक्समा मात्र लागू हुन्छ. यो छ फायरफक्समा 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 बिना ग्राहकहरूलाई समर्थन गर्न। साथै, अपस्ट्रीमको साथ संचार प्रोटोकल या त HTTP वा HTTPS हुन सक्छ TLS संस्करण 1.3 भन्दा कम (यदि अपस्ट्रीमले 1.3 लाई समर्थन गर्दैन)। यो योजनाले अधिकतम लचिलोपन दिन्छ।

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

ESNI कुञ्जीहरू उत्पन्न गर्न हामीले प्रयोग गर्यौं esnitool (CloudFlare को दिमागको उपज पनि)। यी कुञ्जीहरू SNI इन्क्रिप्शन/डिक्रिप्शनका लागि प्रयोग गरिन्छ।
हामीले लिनक्स (डेबियन, अल्पाइन) र MacOS मा go 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 vCPUs, 4 GB RAM होस्टहरू, Linux प्रयोग गर्यौं), र वास्तवमा सम्भावित RPS उच्च छ (हामीले थप शक्तिशाली स्रोतहरूमा 2700 RPS सम्मको तथ्याङ्क प्राप्त गरेका छौं)।

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

स्रोत: www.habr.com