ईएसएनआई के साथ अपनी सार्वजनिक वेबसाइट की सुरक्षा कैसे करें

हेलो हबर, मेरा नाम इल्या है, मैं Exness में प्लेटफ़ॉर्म टीम में काम करता हूँ। हम उन मुख्य बुनियादी ढांचे घटकों को विकसित और कार्यान्वित करते हैं जिनका उपयोग हमारी उत्पाद विकास टीमें करती हैं।

इस लेख में, मैं सार्वजनिक वेबसाइटों के बुनियादी ढांचे में एन्क्रिप्टेड एसएनआई (ईएसएनआई) तकनीक को लागू करने के अपने अनुभव को साझा करना चाहूंगा।

इस तकनीक के उपयोग से सार्वजनिक वेबसाइट के साथ काम करते समय सुरक्षा का स्तर बढ़ेगा और कंपनी द्वारा अपनाए गए आंतरिक सुरक्षा मानकों का अनुपालन होगा।

सबसे पहले, मैं यह बताना चाहूंगा कि तकनीक मानकीकृत नहीं है और अभी भी ड्राफ्ट में है, लेकिन क्लाउडफ्लेयर और मोज़िला पहले से ही इसका समर्थन करते हैं (में) ड्राफ्ट01). इसने हमें ऐसे प्रयोग के लिए प्रेरित किया.

सिद्धांत का एक छोटा सा

ईएसएनआई टीएलएस 1.3 प्रोटोकॉल का एक विस्तार है जो टीएलएस हैंडशेक "क्लाइंट हैलो" संदेश में एसएनआई एन्क्रिप्शन की अनुमति देता है। यहां बताया गया है कि ईएसएनआई समर्थन के साथ क्लाइंट हैलो कैसा दिखता है (सामान्य एसएनआई के बजाय हम ईएसएनआई देखते हैं):

 ईएसएनआई का उपयोग करने के लिए, आपको तीन घटकों की आवश्यकता है:

• डीएनएस; 
• ग्राहक सहायता;
• सर्वर साइड समर्थन.

डीएनएस

आपको दो DNS रिकॉर्ड जोड़ने होंगे - Aऔर TXT (TXT रिकॉर्ड में सार्वजनिक कुंजी होती है जिसके साथ ग्राहक SNI को एन्क्रिप्ट कर सकता है) - नीचे देखें। इसके अलावा समर्थन भी होना चाहिए DOH (HTTPS पर DNS) क्योंकि उपलब्ध क्लाइंट (नीचे देखें) DoH के बिना ESNI समर्थन सक्षम नहीं करते हैं। यह तर्कसंगत है, क्योंकि ईएसएनआई का तात्पर्य उस संसाधन के नाम के एन्क्रिप्शन से है जिसे हम एक्सेस कर रहे हैं, यानी यूडीपी पर डीएनएस तक पहुंचने का कोई मतलब नहीं है। इसके अलावा, उपयोग DNSSEC आपको इस परिदृश्य में कैश पॉइज़निंग हमलों से बचाने की अनुमति देता है।

अभी उपलब्ध है कई डीओएच प्रदाता, उनमें से:

• CloudFlare
• OpenDNS
• गूगल

CloudFlare राज्यों (मेरा ब्राउज़र जांचें → एन्क्रिप्टेड एसएनआई → और जानें) कि उनके सर्वर पहले से ही ईएसएनआई का समर्थन करते हैं, यानी, डीएनएस में क्लाउडफ्लेयर सर्वर के लिए हमारे पास कम से कम दो रिकॉर्ड हैं - ए और टीएक्सटी। नीचे दिए गए उदाहरण में हम 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 के साथ) का उपयोग करना चाहिए और दो प्रविष्टियाँ जोड़नी चाहिए। 

ग्राहक सहेयता

अगर हम ब्राउज़र के बारे में बात कर रहे हैं, तो फिलहाल समर्थन केवल फ़ायरफ़ॉक्स में लागू किया गया है. यहां यहां फ़ायरफ़ॉक्स में ईएसएनआई और डीओएच समर्थन को सक्रिय करने के निर्देश दिए गए हैं। ब्राउज़र कॉन्फ़िगर होने के बाद, हमें कुछ इस तरह देखना चाहिए:

लिंक ब्राउज़र की जाँच करने के लिए.

बेशक, ईएसएनआई का समर्थन करने के लिए टीएलएस 1.3 का उपयोग किया जाना चाहिए, क्योंकि ईएसएनआई टीएलएस 1.3 का विस्तार है।

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

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

वर्तमान में, ESNI nginx/apache इत्यादि जैसे वेब सर्वरों द्वारा समर्थित नहीं है, क्योंकि वे OpenSSL/BoringSSL के माध्यम से TLS के साथ काम करते हैं, जो आधिकारिक तौर पर ESNI का समर्थन नहीं करते हैं।

इसलिए, हमने अपना खुद का फ्रंट-एंड कंपोनेंट (ईएसएनआई रिवर्स प्रॉक्सी) बनाने का फैसला किया, जो ईएसएनआई के साथ टीएलएस 1.3 समाप्ति और अपस्ट्रीम पर प्रॉक्सी HTTP (एस) ट्रैफिक का समर्थन करेगा, जो ईएसएनआई का समर्थन नहीं करता है। यह प्रौद्योगिकी को मुख्य घटकों को बदले बिना पहले से मौजूद बुनियादी ढांचे में उपयोग करने की अनुमति देता है - अर्थात, मौजूदा वेब सर्वर का उपयोग करना जो ईएसएनआई का समर्थन नहीं करते हैं। 

स्पष्टता के लिए, यहाँ एक चित्र है:

मैंने ध्यान दिया कि प्रॉक्सी को ईएसएनआई के बिना ग्राहकों का समर्थन करने के लिए ईएसएनआई के बिना टीएलएस कनेक्शन को समाप्त करने की क्षमता के साथ डिजाइन किया गया था। साथ ही, अपस्ट्रीम के साथ संचार प्रोटोकॉल 1.3 से कम टीएलएस संस्करण के साथ HTTP या HTTPS हो सकता है (यदि अपस्ट्रीम 1.3 का समर्थन नहीं करता है)। यह योजना अधिकतम लचीलापन प्रदान करती है।

ईएसएनआई समर्थन का कार्यान्वयन जारी है go हमने उधार लिया था CloudFlare. मैं तुरंत यह नोट करना चाहूंगा कि कार्यान्वयन स्वयं काफी गैर-तुच्छ है, क्योंकि इसमें मानक पुस्तकालय में परिवर्तन शामिल हैं क्रिप्टो/टीएलएस और इसलिए "पैचिंग" की आवश्यकता है गरोठ असेंबली से पहले.

ईएसएनआई कुंजी उत्पन्न करने के लिए हमने इसका उपयोग किया esnitool (क्लाउडफ्लेयर के दिमाग की उपज भी)। इन कुंजियों का उपयोग SNI एन्क्रिप्शन/डिक्रिप्शन के लिए किया जाता है।
हमने लिनक्स (डेबियन, अल्पाइन) और मैकओएस पर गो 1.13 का उपयोग करके बिल्ड का परीक्षण किया। 

परिचालन सुविधाओं के बारे में कुछ शब्द

ईएसएनआई रिवर्स प्रॉक्सी प्रोमेथियस प्रारूप में मेट्रिक्स प्रदान करता है, जैसे आरपीएस, अपस्ट्रीम विलंबता और प्रतिक्रिया कोड, असफल/सफल टीएलएस हैंडशेक और टीएलएस हैंडशेक अवधि। पहली नज़र में, यह मूल्यांकन करने के लिए पर्याप्त लगा कि प्रॉक्सी ट्रैफ़िक को कैसे संभालती है। 

हमने उपयोग से पहले लोड परीक्षण भी किया। परिणाम नीचे:

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 

हमने ईएसएनआई रिवर्स प्रॉक्सी का उपयोग करके और उसके बिना योजना की तुलना करने के लिए पूरी तरह से गुणात्मक लोड परीक्षण किया। हमने मध्यवर्ती घटकों में "हस्तक्षेप" को खत्म करने के लिए स्थानीय स्तर पर ट्रैफ़िक "डाला"।

इसलिए, ईएसएनआई समर्थन और HTTP से अपस्ट्रीम पर प्रॉक्सी करने से, हमें एक उदाहरण से लगभग ~550 आरपीएस प्राप्त हुए, ईएसएनआई रिवर्स प्रॉक्सी की औसत सीपीयू/रैम खपत के साथ:

• 80% सीपीयू उपयोग (4 वीसीपीयू, 4 जीबी रैम होस्ट, लिनक्स)
• 130 एमबी मेम आरएसएस

तुलना के लिए, टीएलएस (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 वीसीपीयू, 4 जीबी रैम होस्ट, लिनक्स का उपयोग किया), और वास्तव में संभावित आरपीएस अधिक है (हमें अधिक शक्तिशाली संसाधनों पर 2700 आरपीएस तक के आंकड़े प्राप्त हुए)।

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

स्रोत: www.habr.com