HTTPS پراکسی کا مطلب دو TLS روابط ہیں، ایک نہیں

HTTPS پراکسی کا لفظ آپ کے کلائنٹ اور پراکسی کے درمیان منتقلی بیان کرتا ہے، اس سے زیادہ کچھ نہیں۔ یہ نہیں بتاتا کہ اس کے پیچھے کی ویب سائٹ اسی رابطے سے خفیہ ہے، اور نہیں بتاتا کہ پراکسی صفحہ پڑھ سکتی ہے۔ جب آپ دونوں رابطوں کو الگ کرتے ہیں تو سرٹیفکیٹ کی غلطیاں پراسرار رہنا چھوڑ دیتی ہیں اور VPN سے موازنہ ٹھوس ہو جاتا ہے۔

دو سروں کے جوڑے، دو تصدیقیں

عام ٹنل موڈ میں دو TLS تعلقات ہوتے ہیں۔ پہلا آپ کے کلائنٹ سے پراکسی تک جاتا ہے اور پراکسی کی تصدیق کرتا ہے۔ دوسرا آپ کے کلائنٹ سے ٹنل کے اندر ویب سائٹ تک جاتا ہے اور ویب سائٹ کی تصدیق کرتا ہے۔ یہ الگ الگ ناکام ہوتے ہیں اور الگ الگ ترتیب دیے جاتے ہیں۔

ان کے اعتماد کے الگ فیصلے، الگ سرٹیفکیٹ زنجیریں اور الگ ناکامی کے پیغامات ہیں۔ تنظیمی CA استعمال کرنے والی پراکسی اور عوامی زنجیر استعمال کرنے والی عوامی ویب سائٹ کو جائز طور پر مختلف تصدیقی ترتیب درکار ہو سکتی ہے، اور یہ غلط ترتیب نہیں ہے۔

انہیں دو رابطے سمجھیں جو اتفاق سے ایک ساکٹ بانٹتے ہیں، کیونکہ وہ ایسے ہی ہیں۔

CONNECT اصل میں کس چیز کی ٹنل بناتا ہے

کلائنٹ میزبان اور پورٹ بتانے والی CONNECT درخواست بھیجتا ہے، اور پراکسی اس ہدف تک TCP رابطہ کھولتی ہے۔ پراکسی کے جواب کے بعد، آگے آنے والے بائٹس بغیر تشریح کے منتقل کیے جاتے ہیں، اسی لیے ویب سائٹ کا TLS ہینڈ شیک پراکسی سے بغیر کسی تغیر کے گزرتا ہے۔ اس طرح پراکسی منزل کا نام اور رابطے کی میٹا ڈیٹا جان لیتی ہے، اور اس ترتیب سے ڈکرپٹ شدہ صفحات نہیں پاتی۔

یہی فرق ٹنل موڈ کی پوری سلامتی کی دلیل ہے، اور یہی اس کی حد بھی۔

پراکسی کے مرحلے پر TLS کے بغیر HTTP پراکسی پھر بھی CONNECT کے ذریعے HTTPS ویب سائٹ لے جاتی ہے۔ کلائنٹ اور پراکسی کے درمیان تبادلہ کھلا ہے جبکہ ویب سائٹ کا رابطہ نہیں، اور پورے معاملے کو HTTPS پراکسی کہنا اسی فرق کو چھپاتا ہے۔

کون سا سرٹیفکیٹ ناکام ہوا

جب تصدیق ناکام ہو تو کوئی بھی اعتماد کی ترتیب بدلنے سے پہلے غلطی میں بتایا گیا سرا پڑھیں۔ دونوں ناکامیاں ٹرمینل میں ایک جیسی لگتی ہیں اور بالکل مختلف حل کی طرف اشارہ کرتی ہیں، اسی لیے پہلا سوال ہمیشہ یہ ہوتا ہے کہ کون سا رابطہ مسترد ہوا۔

curl اسی وجہ سے اختیارات الگ کرتا ہے۔ پراکسی CA فائل پراکسی کی تصدیق ترتیب دیتی ہے، جبکہ CA فائل سرور کی تصدیق ترتیب دیتی ہے، اور لاگو ٹرسٹ اسٹور کا رویہ بھی اس پر منحصر ہے کہ curl کیسے بنایا گیا۔

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

جانچ کو دبانا مرمت نہیں ہے۔ یہ کسی بھی سرے کے بارے میں کچھ ثابت نہیں کرتا۔

معائنہ ایک مختلف ترتیب ہے

TLS معائنہ ٹنل بنانا نہیں ہے۔ معائنہ کرنے والا بیچوان ویب سائٹ کی طرف اعتماد کا تعلق ختم کرتا ہے اور کلائنٹ کو اپنا سرٹیفکیٹ پیش کرتا ہے، لہذا کلائنٹ سائٹ کی بجائے بیچوان کی تصدیق کرتا ہے۔ منظور شدہ ڈیزائن کے تحت یہ جائز ہو سکتا ہے، اور یہ بائٹ بہ بائٹ منتقلی سے بنیادی طور پر مختلف دعوی ہے۔ یہ مت سمجھیں کہ ہر پراکسی معائنہ کرتی ہے، اور یہ بھی مت سمجھیں کہ خفیہ پراکسی مرحلہ اسے خارج کر دیتا ہے۔

آپ کے ٹرسٹ اسٹور میں تنظیمی CA اس بات کا اشارہ ہے کہ آپ کس ترتیب میں ہیں، ثبوت نہیں۔ سرٹیفکیٹ زنجیر سے اندازہ لگانے کے بجائے ڈیزائن پوچھیں۔

یہ دونوں ترتیبیں اس سوال کے مختلف جواب دیتی ہیں کہ صفحہ کون پڑھ سکتا ہے۔

پراکسی اور VPN کا موازنہ انہی چار سطروں پر کریں

موازنہ صرف اس وقت کارآمد ہوتا ہے جب دونوں تعیناتیاں ایک ہی انداز میں بیان کی جائیں۔

ایک درخواست کے لیے ترتیب دی گئی پراکسی صرف اسی درخواست کو ڈھانپتی ہے۔ یہ ڈیوائس کے ہر عمل کو اپنے ذریعے نہیں بھیجتی، اور مثال کا کمانڈ بالکل اسی قدر تنگ ہے۔ VPN کی کوریج اس کی روٹنگ اور ایپلیکیشن پالیسی پر منحصر ہے، جس کا بھی اندازہ لگانے کے بجائے جائزہ لینا ضروری ہے۔ کوئی بھی آپشن صرف اس لیے سب کچھ ڈھانپ نہیں لیتا کہ وہ نصب ہو گیا۔

ہر آپشن کے لیے وہ چار سطریں لکھیں اور بحث عموماً خود طے ہو جاتی ہے۔ مفید موازنہ یہ نہیں کہ کون سا لیبل زیادہ خفیہ لگتا ہے۔ یہ ہے کہ کون سے حصے محفوظ ہیں، ان کے سروں پر کس کی تصدیق ہوتی ہے، آپ کن بیچوانوں پر بھروسہ کرتے ہیں، اور پالیسی اصل میں کون سی ٹریفک شامل کرتی ہے۔