موزیلا نے فائر فاکس کی مستحکم برانچ کے صارفین کے لیے ECH (انکرپٹڈ کلائنٹ ہیلو) میکانزم کے لیے تعاون کو شامل کرنے کا اعلان کیا ہے، جو ESNI (انکرپٹڈ سرور نیم اشارے) ٹیکنالوجی کی ترقی کو جاری رکھے ہوئے ہے اور اسے TLS سیشنز کے پیرامیٹرز کے بارے میں معلومات کو خفیہ کرنے کے لیے ڈیزائن کیا گیا ہے۔ جیسا کہ درخواست کردہ ڈومین نام۔ ECH کے ساتھ کام کرنے کا کوڈ اصل میں Firefox 85 ریلیز میں شامل کیا گیا تھا، لیکن اسے بطور ڈیفالٹ غیر فعال کر دیا گیا تھا۔ کروم نے آہستہ آہستہ کروم 115 کی ریلیز سے شروع ہونے والی ECH سپورٹ کو شامل کرنا شروع کیا۔
کے ساتھ منسلک کرنے کے علاوہ کے بعد سے سرور درخواست کردہ ڈومین کی معلومات DNS کے ذریعے لیک کی گئی ہے۔ مکمل تحفظ کے لیے، ECH کے علاوہ، آپ کو DNS ٹریفک کو خفیہ کرنے کے لیے HTTPS پر DNS یا TLS پر DNS استعمال کرنا چاہیے۔ Firefox ترتیبات میں HTTPS پر DNS کو فعال کیے بغیر ECH استعمال نہیں کرے گا۔ آپ اس صفحہ پر اپنے براؤزر میں ECH سپورٹ چیک کر سکتے ہیں۔
فائر فاکس میں ECH سپورٹ کو بطور ڈیفالٹ فعال کرنے والے عوامل میں سے ایک Cloudflare کا کچھ دن پہلے اپنے مواد کی ترسیل کے نیٹ ورک میں ECH سپورٹ کو شامل کرنا تھا۔ عملی طور پر، چونکہ ECH استعمال کرتے وقت درخواست کردہ میزبانوں کے بارے میں ڈیٹا تجزیہ سے پوشیدہ ہے، لہذا Cloudflare CDN کا استعمال کرتے ہوئے ناپسندیدہ سائٹس کو فلٹر کرنے اور بلاک کرنے کے لیے اب پورے Cloudflare نیٹ ورک کو بلاک کرنے، ECH سے تمام درخواستوں کو مسدود کرنے، یا جعلی روٹ سرٹیفکیٹس کا استعمال کرتے ہوئے HTTPS مداخلت کو منظم کرنے کی ضرورت ہوگی۔ صارف کے نظام پر.
ابتدائی طور پر، متعدد HTTPS سائٹس کے ایک IP ایڈریس پر کام کو منظم کرنے کے لیے، TLS ایکسٹینشن SNI کا استعمال کیا گیا، جس میں ایک خفیہ مواصلاتی چینل قائم کرنے سے پہلے بھیجے گئے ClientHello پیغام میں درخواست کردہ میزبان کے نام کی نشاندہی کی گئی تھی۔ اس خصوصیت نے کنکشن پروسیسنگ کے ابتدائی مرحلے میں درخواستوں کو ورچوئل ہوسٹس میں تقسیم کرنا ممکن بنایا، لیکن آئی ایس پی کی جانب سے HTTPS ٹریفک کو منتخب طور پر فلٹر کرنا اور تجزیہ کرنا ممکن بنایا کہ صارف کون سی سائٹیں کھولتا ہے، جس نے استعمال کرتے وقت مکمل رازداری حاصل کرنے کی اجازت نہیں دی۔ HTTPS
اس مسئلے کو حل کرنے اور درخواست کردہ سائٹ کے بارے میں معلومات کے رساو کو روکنے کے لیے، بعد میں ایک ESNI توسیع تجویز کی گئی جو میزبان کے نام کے ساتھ ڈیٹا انکرپشن کو نافذ کرتی ہے۔ ESNI کے نفاذ کے دوران، یہ انکشاف ہوا کہ مجوزہ طریقہ کار میزبان ڈیٹا کے لیکیج کے تمام ممکنہ ذرائع کا احاطہ نہیں کرتا اور اس کا استعمال HTTPS سیشنز کی مکمل رازداری کو یقینی بنانے کے لیے کافی نہیں ہے۔ خاص طور پر، پہلے سے قائم کردہ سیشن کو دوبارہ شروع کرتے وقت، واضح متن میں ڈومین کا نام PSK (Pre-Shared Key) TLS ایکسٹینشن کے پیرامیٹرز میں متعین ہوتا رہا۔ اس کے علاوہ، ESNI کو لاگو کرنے کی کوششوں نے مطابقت اور اسکیلنگ کے مسائل کی نشاندہی کی ہے جنہوں نے ESNI کو بڑے پیمانے پر اپنانے سے روکا ہے۔
ESNI کی نشاندہی شدہ خامیوں کو مدنظر رکھتے ہوئے، ایک نیا یونیورسل ECH میکانزم تیار کیا گیا جو کسی بھی TLS ایکسٹینشن کے پیرامیٹرز کی خفیہ کاری کی اجازت دیتا ہے۔ تکنیکی طور پر، ECH اور ESNI کے درمیان بنیادی فرق یہ ہے کہ انفرادی فیلڈز کے بجائے، پورے ClientHello پیغام کو ایک ساتھ انکرپٹ کیا جاتا ہے۔ ECH میں ClientHello کو دو الگ الگ پیغامات میں تقسیم کرنا شامل ہے - خفیہ کردہ ClientHelloInner پیغام (SNI Inner) اور غیر خفیہ کردہ بنیادی ClientHelloOuter پیغام (SNI Outer)۔ ایک غیر خفیہ کردہ SNI Outer میں غیر رازداری کا ڈیٹا ہوتا ہے جیسے کہ TLS ورژن اور استعمال شدہ سائفرز کی فہرست، نیز ایک عام ڈومین نام جو کہ درخواست کردہ ڈومین کے اصل نام سے اوورلیپ نہیں ہوتا ہے۔ مثال کے طور پر، تمام Cloudflare کلائنٹس کے لیے، غیر خفیہ کردہ SNI Outer عام میزبان "cloudflare-ech.com" کی وضاحت کرتا ہے، لیکن درخواست کردہ میزبان کا اصل نام انکرپٹڈ SNI Inner میں منتقل ہوتا ہے اور تجزیہ کے لیے دستیاب نہیں ہے۔
ECH ایک مختلف انکرپشن کلیدی تقسیم کی اسکیم کا بھی استعمال کرتا ہے: عوامی کلیدی معلومات TXT ریکارڈز کے بجائے HTTPSSVC DNS ریکارڈز میں منتقل کی جاتی ہیں۔ HPKE (Hybrid Public Key Encryption) میکانزم پر مبنی تصدیق شدہ اینڈ ٹو اینڈ انکرپشن کلید کو حاصل کرنے اور انکرپٹ کرنے کے لیے استعمال کیا جاتا ہے۔ ECH سرور سے محفوظ کلید کی منتقلی کو بھی سپورٹ کرتا ہے، جسے کلیدی گردش کی صورت میں استعمال کیا جا سکتا ہے۔ سرور اور DNS کیشے سے پرانی چابیاں بازیافت کرنے کے مسائل کو حل کرنے کے لیے۔
ماخذ: opennet.ru
