WSS ٹنل کی خفیہ کاری ایپ میں نہیں، TLS ٹرمنیٹر پر رکتی ہے
ایک wss:// URL ایک ہاپ پر TLS کا ثبوت دیتا ہے۔ پے لوڈ کی اپنی خفیہ کاری ہے یا نہیں، یہ اس پر منحصر ہے کہ کلائنٹ اندر کیا رکھتا ہے اور وہ TLS کون ختم کرتا ہے۔
محفوظ WebSocket کے اندر لے جایا جانے والا ٹنل بالکل اتنی ہی خفیہ کاری رکھتا ہے جتنی کلائنٹ نے اس میں رکھی ہو، اس سے زیادہ نہیں۔ wss:// اسکیم کہتی ہے کہ TLS ایک ہاپ پر ایک کنکشن کی حفاظت کرتا ہے۔ یہ اس بارے میں کچھ نہیں کہتی کہ WebSocket پیغامات کے اندر موجود بائٹس الگ سے محفوظ ہیں یا نہیں، اور جب درمیان میں کوئی چیز TLS ختم کرتی ہے تو آپ کا ٹریفک کون پڑھ سکتا ہے یہ اسی فرق سے طے ہوتا ہے۔
دو پرتیں جو ایک جیسی لگتی ہیں
محفوظ WebSocket وہ TLS ہے جس پر WebSocket ہینڈ شیک کیا جاتا ہے، جیسا کہ RFC 6455 اپنے کنکشن اور سیکیورٹی کے حصوں میں بیان کرتا ہے۔ TLS پرت سرور کی تصدیق کرتی ہے اور اسٹریم کو خفیہ کرتی ہے، پھر WebSocket پرت وہ فریم کرتی ہے جو ایپلیکیشن بھیجنے کا فیصلہ کرتی ہے۔
یہ دو خودمختار فیصلے ہیں، اور پورے راستے پر ایک ہی تالا کھینچنے والا خاکہ دوسرے کو چھپا دیتا ہے۔ پوچھیں کہ TLS کنکشن کون ختم کرتا ہے۔ پھر پوچھیں کہ کلائنٹ ہر پیغام کے اندر کیا رکھتا ہے۔ تعیناتی کے بارے میں باقی سب کچھ انہی دو جوابوں سے نکلتا ہے۔
ڈیزائن A: نقل و حمل ہی واحد خفیہ کاری ہے
آسان ڈیزائن میں، کلائنٹ خام IP پیکٹ لیتا ہے اور انہیں WebSocket پیغامات میں لپیٹ دیتا ہے۔ اندر کچھ بھی خفیہ نہیں ہوتا، اس لیے TLS سیشن رکھنے والا جزو سادہ متن پے لوڈ پڑھتا ہے۔ جب وہ جزو آپ کا اپنا ٹنل سرور ہو، تو یہی مطلوبہ آخری نقطہ ہے اور ڈیزائن ہم آہنگ ہے، کیونکہ سرور کو ٹریفک ہر حال میں نظر آنا تھا۔
یہ مختلف انتظام بن جاتا ہے جب راستے میں معائنہ پروکسی بیٹھ کر کلائنٹ کے بھروسے والے سرٹیفکیٹ کے ساتھ TLS ختم کرتی ہے۔ وہ پروکسی اب وہی سادہ متن رکھتی ہے جو سرور رکھتا، اور WebSocket فریمنگ کی کوئی مقدار اسے نہیں بدلتی۔ کلائنٹ کا بھروسہ ذخیرہ یہ نتیجہ سرنگ کھلنے سے بہت پہلے طے کر چکا تھا، کیونکہ اس نے اس نام کے لیے وہ سرٹیفکیٹ قبول کرنے کا انتخاب کیا۔ پروکسی مطلوبہ ہوسٹ اور ہر پیغام کا حجم بھی دیکھتی ہے، جو مزید کچھ ڈکرپٹ کیے بغیر بہت سی سرگرمی کا فنگر پرنٹ لینے کے لیے کافی ہے۔
ڈیزائن B: پے لوڈ اپنی کلیدیں ساتھ لے کر چلتا ہے
دوسرے ڈیزائن میں، کلائنٹ اپنے پیکٹوں کو ایسے VPN پروٹوکول سے خفیہ اور تصدیق شدہ کرتا ہے جس کی اپنی ہم منصب شناخت اور کلیدوں کا تبادلہ ہوتا ہے، پھر نتیجہ WebSocket پیغامات کے اندر لے جاتا ہے۔ یہاں بیرونی TLS ختم کرنے سے ٹریفک نہیں، خفیہ متن ظاہر ہوتا ہے۔ پروکسی پیغامات کے حجم اور وقت دیکھ سکتی ہے، اور پے لوڈ میں اس کے سوا کچھ نہیں۔ یہ بہت چھوٹا انکشاف ہے، اور پھر بھی یہ ایسا میٹا ڈیٹا ہے جس کا جائزے میں نام لینا چاہیے، نظر انداز کرنا نہیں۔
اندرونی پروٹوکول کے اپنے آخری نکات اب بھی سادہ متن دیکھتے ہیں، یہی اس انتظام کا مقصد اور اسی کی حد ہے۔ اگر آخری نقطے پر کوئی جزو خفیہ کاری سے پہلے یا ڈکرپشن کے بعد ڈیٹا پڑھنے کا مجاز ہو، تو اضافی پرت اسے محدود نہیں کرتی۔ کلیدیں، اور انہیں سنبھالنے والا سافٹ ویئر، وہی اہم حد رہتے ہیں۔
VPN لیبل، جانی پہچانی کلائنٹ آئیکن یا مارکیٹنگ صفحہ اس ڈیزائن کے موجود ہونے کا ثبوت نہیں ہے۔ پے لوڈ فارمیٹ پڑھنا ثبوت ہے۔
ٹریس کریں کہ سادہ متن واقعی کہاں ظاہر ہوتا ہے
URL اسکیم آپ کو ایک حقیقت دیتی ہے، باقی انٹرفیس سے لیں۔ نیچے دیے گئے امتحانات ترتیب سے چلائیں، کیونکہ ہر ایک اگلے کو تنگ کرتا ہے:
ss -tnp | grep -E ':(443|8443)\b' ip -br link show type tun openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief tcpdump -ni tun0 -c 5 -X
بیرونی کنکشن سے شروع کریں۔ TLS پورٹ پر ایک طویل العمر TCP سیشن ہی WebSocket حامل کی شکل ہے، اور غیر متعلق ہوسٹ پر دوسرا سیشن مزید گہرائی میں دیکھنے سے پہلے وضاحت کا مستحق ہے۔ پھر کلائنٹ پر ٹنل انٹرفیس ڈھونڈیں، کیونکہ tun یا tap ڈیوائس بتاتی ہے کہ کلائنٹ ایک ایپلیکیشن اسٹریم پروکسی کرنے کے بجائے IP پیکٹ سنبھال رہا ہے۔
ٹنل انٹرفیس پر کیپچر عام طور پر پے لوڈ کا سوال طے کر دیتا ہے۔ وہاں پڑھے جا سکنے والے ہیڈر کا مطلب ہے کہ اندرونی پیکٹ کبھی الگ سے خفیہ نہیں ہوئے، جبکہ زیادہ اینٹروپی والے پے لوڈ کا مطلب ہے کہ ہوئے۔ بیرونی انٹرفیس پر کیپچر دہرائیں اور دونوں کا موازنہ کریں: اگر دونوں بے ترتیب دکھائی دیں، تو اندرونی پرت وہ کام کر رہی ہے جو بیرونی پرت واپس نہیں کر سکتی۔
آپ نے جو بھروسہ واقعی دیا اس کا جائزہ لیں
نصب شدہ کارپوریٹ روٹ سرٹیفکیٹ کلائنٹ کے بھروسہ ذخیرے کے بارے میں حقیقت ہے، اس بات کا بیان نہیں کہ کوئی پروکسی کیا لاگ کرتی ہے یا معائنہ کرتی ہے۔ تعینات پالیسی اور اصل کنکشن راستہ قائم کریں، بجائے اس کے کہ CA کی موجودگی سے رویہ اخذ کریں۔
منظم آلات پر، منتظم سے پوچھیں کہ کون سا جزو TLS ختم کرتا ہے، کلائنٹ پن شدہ سرٹیفکیٹ کی تصدیق کرتا ہے یا عوامی سرٹیفکیٹ کی، اور پے لوڈ فارمیٹ کیا ہے۔ وہ تین جواب ایسی دریافت دیتے ہیں جس کا آپ بعد میں دفاع کر سکیں۔
نتیجہ فیصلے کی بجائے حد کے طور پر لکھیں۔ "TLS معائنہ پروکسی پر ختم ہوتا ہے، اور اندرونی پے لوڈ صرف آخری نکات کے پاس موجود کلیدوں سے الگ سے خفیہ کیا گیا ہے" ایک قابل جانچ بیان ہے جو وینڈر بدلنے پر بھی قائم رہتا ہے۔ "WebSockets محفوظ ہیں" نہیں رہتا۔