HTTPS، DoH، ECH اور VPN مختلف چیزیں چھپاتے ہیں
ہر طریقہ راستے سے کوئی مختلف نگران ہٹاتا ہے اور کوئی بھی سب کو نہیں ہٹاتا۔ ایک اور ٹنل شامل کرنے سے پہلے موازنہ کریں کہ کیا محفوظ ہے۔
ایسے براؤزر میں VPN شامل کرنا جو پہلے ہی HTTPS، DoH اور ECH استعمال کرتا ہے تین حفاظتوں کو ایک میں نہیں جوڑتا؛ یہ بدلتا ہے کہ کون کیا دیکھ سکتا ہے۔ ہر طریقہ کسی مختلف تبادلے سے کوئی مختلف فریق ہٹاتا ہے اور ہر ایک کچھ پیچھے چھوڑ دیتا ہے۔ مفید سوال یہ نہیں کہ کون سب سے مضبوط ہے بلکہ یہ ہے کہ آپ کس نگران کو ہٹانا چاہتے ہیں، کیونکہ جواب طے کرتا ہے کہ ٹنل بالکل مدد کرتی ہے یا نہیں۔ باقی نگرانوں کا موازنہ خصوصیات کی فہرست سے زیادہ مفید ہے۔
چار طریقے، چار نگران
چار رشتوں اور اس فریق سے شروع کریں جسے ہر ایک باہر رکھنے کے لیے بنایا گیا ہے۔ نیچے دیا گیا جدول وہی ہے جو میں جائزے میں استعمال کرتا ہوں، کیونکہ یہ گفتگو کو ٹیکنالوجی کے بجائے نگران کا نام لینے پر مجبور کرتا ہے۔
| Mechanism | Relationship it protects | Observer it does not remove |
|---|---|---|
| HTTPS | The application's TLS connection to its named endpoint | The access network still sees the destination address |
| DoH | The DNS exchange to the selected HTTPS resolver | That resolver sees every query |
| ECH | The sensitive ClientHello fields, where supported and accepted | Destination addresses, and DNS if it is not covered |
| VPN | Covered packets carried to the VPN peer | The VPN operator sees the destinations |
جدول کی قدر وہ ہے جو یہ کہنے سے انکار کرتا ہے۔ یہ طریقوں کی درجہ بندی نہیں کرتا اور یہ دعویٰ نہیں کرتا کہ چاروں استعمال کرنے سے چاروں نگران ہٹ جاتے ہیں۔ ایک کلاؤڈ ویب ایپلیکیشن جو پہلے ہی اپنے کنارے پر TLS ختم کرتی ہے وہ اس تبادلے کے لیے رسائی نیٹ ورک سے محفوظ ہے، اور کوئی ٹنل اس مخصوص خصوصیت کو بہتر نہیں کرتی۔ ٹنل صرف یہ بدل سکتی ہے کہ کون سا نیٹ ورک بیرونی پیکٹ دیکھتا ہے اور اب راستے پر کون سا آپریٹر ہے۔
HTTPS واقعی کیا چھپاتا ہے
HTTPS کلائنٹ اور اس اینڈ پوائنٹ کے درمیان ایپلیکیشن کا تبادلہ محفوظ کرتا ہے جس کا نام سرٹیفکیٹ لیتا ہے۔ یہ منزل کا پتہ نہیں چھپاتا، یہ نہیں چھپاتا کہ کنکشن ہوا، اور نام بھی نہیں چھپاتا جب تک ECH شامل نہ ہو۔ سرٹیفکیٹ کی تصدیق حفاظت کا حصہ ہے، اس کے گرد کوئی رسمیہ نہیں۔
VPN کو اس TLS کو ختم کرنے کی ضرورت نہیں، اور فارورڈنگ اخراج کو ایپلیکیشن کا مستند اینڈ پوائنٹ نہیں سمجھا جانا چاہیے۔ اگر کوئی ڈیزائن اخراج کو ڈکرپٹ کرنے دیتا ہے تو وہ مختلف اعتماد کے بیان کے ساتھ مختلف فن تعمیر ہے۔
DoH اور ECH کیا منتقل کرتے ہیں اور کیا چھوڑ دیتے ہیں
DoH ڈی این ایس کے تبادلے کو HTTPS ریزالور کی طرف منتقل کرتا ہے، یعنی وہ ریزالور مقامی نیٹ ورک کے ریزالور کے بجائے آپ کے سوالات دیکھتا ہے۔ یہ ایک حقیقی اور محدود تبدیلی ہے: منتخب ریزالور ایسا فریق بن جاتا ہے جو سوالات کو ان پتوں سے جوڑ سکتا ہے جن سے آپ بعد میں جڑتے ہیں، اور یہی وہ ربط ہے جس پر دستاویز RFC 8484 بحث کرتی ہے۔ خفیہ کردہ ترسیل وصول کنندہ کو ان سوالات سے بے خبر نہیں کرتی جن کا وہ جواب دیتا ہے۔
ECH کلائنٹ ہیلو کے حساس حصے کی حفاظت کرتا ہے تاکہ راستے پر موجود غیر فعال نگران مطلوبہ سرور کا نام نہ پڑھ سکے۔ یہ معاون تعیناتی اور سرور و نیٹ ورک کی قبولیت پر منحصر ہے، اور دوسرے راستے اپنی جگہ چھوڑ دیتا ہے: منزل کے پتے نظر آتے رہتے ہیں، اور ڈی این ایس اب بھی نام ظاہر کر سکتا ہے۔
دوسری چیز جو ECH نہیں کرتا وہ خود کو ثابت کرنا ہے۔ TLS 1.3 استعمال کرنے والا کنکشن اس بات کا ثبوت نہیں کہ ECH قبول ہوا، اور ایسا براؤزر جو ECH ایسے سرور کو پیش کرے جو اسے معاون نہیں، خاموشی سے واپس آ جاتا ہے۔ پروٹوکول ورژن سے اندازہ لگانے کے بجائے کنکشن کی حقیقی حالت دیکھیں۔
پورے موازنے کی عمومی شکل یہی ہے: ہر طریقہ اپنی سطح پر جانچا جاتا ہے، اور ان میں سے کوئی دوسرے کی کامیابی سے تصدیق شدہ نہیں۔
VPN کیا منتقل کرتا ہے اور کیا شامل کرتا ہے
جب ویب ٹریفک کسی VPN میں داخل ہوتی ہے تو رسائی نیٹ ورک انفرادی ایپلیکیشن کنکشنز کے بجائے VPN ساتھی کے ساتھ بیرونی تبادلہ دیکھتا ہے، اور VPN آپریٹر آگے کے راستے پر ایک مقام لے لیتا ہے۔ یہ اعتماد کی حد کو منتقل کرنا ہے، اسے ہٹانا نہیں۔ آپریٹر اب دیکھتا ہے کہ آپ کن منزلوں تک پہنچتے ہیں، چاہے مواد آخر تک خفیہ رہے۔ یہ بہتری ہے یا نہیں، اس کا انحصار مکمل طور پر اس بات پر ہے کہ آپ ان دو فریقوں میں سے کس پر کم بھروسا کرتے ہیں۔
یہ کرتے وقت ایپلیکیشن کا HTTPS اور مطلوبہ ریزالور تحفظ برقرار رکھیں۔ ٹنل سرٹیفکیٹ کی تصدیق کا متبادل نہیں، اور ٹریفک کے ٹنل سے گزرنے کی وجہ سے ریزالور کے تحفظات بند کرنا متبادل کے بغیر ایک کنٹرول ہٹانا ہے۔
ضرورت سے انتخاب
اصل ضرورت بیان کریں، کیونکہ ڈیزائن کا فیصلہ وہی کرتی ہے۔ نجی وسائل تک رسائی، زیرِ انتظام اخراجی مقام، رسائی نیٹ ورک کی مخصوص دھمکی اور ڈیوائس کی اجازت چار مختلف ضرورتیں ہیں جن کے چار مختلف جواب ہیں، اور صرف عوامی کلاؤڈ ایپلیکیشنز استعمال کرنے والی کمپنی کو بھی اجازت اور ڈیٹا کی دیکھ بھال طے کرنی ہوتی ہے۔ اضافی تہیں مناسب ہو سکتی ہیں مگر ایک دوسرے کا متبادل نہیں۔ زیادہ پیچیدہ کنکشن گمنامی کی پیمائش نہیں اور بذاتِ خود حفاظتی دلیل بھی نہیں۔
ECH کی تفصیل، RFC 9849، اس لیے پڑھنے کے قابل ہے کہ طریقہ کیا ڈھانپتا ہے اور کیا نہیں، اور یہ ان راستوں کے بارے میں دیانت دار ہے جنہیں اکیلا چھوڑ دیتا ہے۔ طریقوں کا موازنہ اس نگران کے لحاظ سے کریں جو ہر ایک ہٹاتا ہے، وہ نگران لکھ لیں، پھر فیصلہ کریں کہ اضافی تہہ اسی کو مخاطب کر رہی ہے یا نہیں۔ اگر جواب یہ ہو کہ نگران پہلے ہی آپ کے خطرے کے ماڈل سے باہر تھا تو ٹنل بغیر فائدے کے خرچ ہے۔