ESNI کے ساتھ اپنی عوامی ویب سائٹ کی حفاظت کیسے کریں۔

ہیلو ہیبر، میرا نام الیا ہے، میں Exness میں پلیٹ فارم ٹیم میں کام کرتا ہوں۔ ہم بنیادی ڈھانچے کے اجزاء کو تیار اور نافذ کرتے ہیں جو ہماری مصنوعات کی ترقی کی ٹیمیں استعمال کرتی ہیں۔

اس مضمون میں، میں عوامی ویب سائٹس کے بنیادی ڈھانچے میں انکرپٹڈ SNI (ESNI) ٹیکنالوجی کو نافذ کرنے کے اپنے تجربے کا اشتراک کرنا چاہوں گا۔

Использование этой технологии позволит повысить уровень безопасности при работе с публичным веб-сайтом и соответствовать внутренним стандартам безопасности, принятым в Компании.

سب سے پہلے، میں یہ بتانا چاہوں گا کہ ٹیکنالوجی معیاری نہیں ہے اور ابھی بھی مسودے میں ہے، لیکن CloudFlare اور Mozilla پہلے ہی اس کی حمایت کر رہے ہیں ( مسودہ 01)۔ اس نے ہمیں اس طرح کے تجربے کے لیے ترغیب دی۔

تھوڑا سا اصول

ای ایس این آئی TLS 1.3 پروٹوکول کی توسیع ہے جو TLS ہینڈ شیک "کلائنٹ ہیلو" پیغام میں SNI انکرپشن کی اجازت دیتا ہے۔ یہ ہے کلائنٹ ہیلو ESNI سپورٹ کے ساتھ کیسا لگتا ہے (معمول کے SNI کے بجائے ہم ESNI دیکھتے ہیں):

 ESNI استعمال کرنے کے لیے، آپ کو تین اجزاء کی ضرورت ہے:

• ڈی این ایس؛ 
• کلائنٹ سپورٹ؛
• سرور سائیڈ سپورٹ۔

DNS

آپ کو دو DNS ریکارڈ شامل کرنے کی ضرورت ہے - Aاور TXT (TXT ریکارڈ عوامی کلید پر مشتمل ہے جس کے ساتھ کلائنٹ SNI کو خفیہ کر سکتا ہے) - نیچے دیکھیں۔ اس کے علاوہ، حمایت ہونا ضروری ہے ڈی او ایچ۔ (DNS over HTTPS), так как доступные клиенты (см. ниже) не активируют поддержку ESNI без DoH. Это логично, так как ESNI подразумевает шифрацию имени ресурса, к которому мы обращаемся, то есть бессмысленно обращаться к DNS по UDP. Более того,  использование 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 کو ختم کرنے اور upstream کے لیے پراکسی HTTP(S) ٹریفک کو سپورٹ کرے گا، جو ESNI کو سپورٹ نہیں کرتا ہے۔ یہ ٹیکنالوجی کو پہلے سے موجود بنیادی ڈھانچے میں استعمال کرنے کی اجازت دیتا ہے، بنیادی اجزاء کو تبدیل کیے بغیر - یعنی، موجودہ ویب سرورز کا استعمال کرتے ہوئے جو ESNI کو سپورٹ نہیں کرتے ہیں۔ 

وضاحت کے لیے، یہاں ایک خاکہ ہے:

میں نوٹ کرتا ہوں کہ پراکسی کو ESNI کے بغیر TLS کنکشن کو ختم کرنے، ESNI کے بغیر کلائنٹس کی مدد کرنے کی صلاحیت کے ساتھ ڈیزائن کیا گیا تھا۔ نیز، اپ اسٹریم کے ساتھ کمیونیکیشن پروٹوکول یا تو HTTP یا HTTPS ہوسکتا ہے جس کا TLS ورژن 1.3 سے کم ہو (اگر اپ اسٹریم 1.3 کو سپورٹ نہیں کرتا ہے)۔ یہ اسکیم زیادہ سے زیادہ لچک دیتی ہے۔

پر ESNI سپورٹ کا نفاذ go ہم سے ادھار لیا CloudFlare کے. میں ابھی نوٹ کرنا چاہوں گا کہ عمل درآمد خود ہی کافی غیر معمولی ہے، کیونکہ اس میں معیاری لائبریری میں تبدیلیاں شامل ہیں crypto/tls اور اس لیے "پیچنگ" کی ضرورت ہے جوروٹ اسمبلی سے پہلے.

ESNI کیز بنانے کے لیے ہم نے استعمال کیا۔ esnitool (тоже детище CloudFlare). Данные ключи используются для шифрации/дешифрации SNI.
ہم نے لینکس (Debian، Alpine) اور MacOS پر go 1.13 کا استعمال کرتے ہوئے تعمیر کا تجربہ کیا۔ 

آپریشنل خصوصیات کے بارے میں چند الفاظ

ESNI ریورس پراکسی Prometheus فارمیٹ میں میٹرکس فراہم کرتی ہے، جیسے 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% سی پی یو استعمال (4 وی سی پی یو، 4 جی بی ریم ہوسٹس، لینکس)
• 130 ایم بی میم آر ایس ایس

مقابلے کے لیے، TLS (HTTP پروٹوکول) کے بغیر اسی nginx upstream کے لیے 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