ESNI सह तुमच्या सार्वजनिक वेबसाइटचे संरक्षण कसे करावे

हॅलो हॅब्र, माझे नाव इल्या आहे, मी Exness येथे प्लॅटफॉर्म टीममध्ये काम करतो. आमचे उत्पादन विकास कार्यसंघ वापरत असलेले मूलभूत पायाभूत घटक आम्ही विकसित आणि अंमलात आणतो.

या लेखात, मी सार्वजनिक वेबसाइट्सच्या पायाभूत सुविधांमध्ये एनक्रिप्टेड SNI (ESNI) तंत्रज्ञान लागू करण्याचा माझा अनुभव शेअर करू इच्छितो.

सार्वजनिक वेबसाइटवर काम करताना आणि कंपनीने स्वीकारलेल्या अंतर्गत सुरक्षा मानकांचे पालन करताना या तंत्रज्ञानाचा वापर सुरक्षिततेची पातळी वाढवेल.

सर्व प्रथम, मी हे निदर्शनास आणू इच्छितो की तंत्रज्ञान प्रमाणित नाही आणि अद्याप मसुद्यात आहे, परंतु क्लाउडफ्लेअर आणि मोझिला आधीच त्यास समर्थन देतात (मध्ये मसुदा 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 प्रदाता, त्यापैकी:

• CloudFlare
• OpenDNS
• Google

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 मध्ये लागू केले जाते. तो आहे फायरफॉक्समध्ये 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 आणि म्हणून "पॅचिंग" आवश्यक आहे गरोट विधानसभा आधी.

ESNI की व्युत्पन्न करण्यासाठी आम्ही वापरले esnitool (क्लाउडफ्लेअरचाही विचार). या की SNI एन्क्रिप्शन/डिक्रिप्शनसाठी वापरल्या जातात.
आम्ही Linux (डेबियन, अल्पाइन) आणि 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 रिव्हर्स प्रॉक्सी वापरून आणि त्याशिवाय योजनेची तुलना करण्यासाठी पूर्णपणे गुणात्मक लोड चाचणी केली. मध्यवर्ती घटकांमधील "हस्तक्षेप" दूर करण्यासाठी आम्ही स्थानिक पातळीवर रहदारी "ओतली".

त्यामुळे, HTTP वरून ESNI समर्थन आणि अपस्ट्रीम प्रॉक्सीसह, आम्हाला 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