TLS پننگ اور VPN رسائی مختلف سوالات کے جواب دیتے ہیں
پن طے کرتا ہے کہ ایپ کس سرور پر اعتماد کرتی ہے؛ VPN پالیسی طے کرتی ہے کہ کون نیٹ ورک تک پہنچتا ہے۔ کوئی بھی اجازت یا گمشدہ ڈیوائس کا احاطہ نہیں کرتا۔
ایک نجی موبائل ایپ کو VPN کے پیچھے رکھیں اور کوئی سمجھدار شخص پوچھے گا کہ کیا اسے اب بھی سرٹیفکیٹ پننگ کی ضرورت ہے۔ سوال دو مساوی کنٹرولز میں سے انتخاب جیسا لگتا ہے، مگر دراصل یہ دو مختلف دروازوں کے بارے میں سوال ہے۔ VPN طے کرتا ہے کہ اس ڈیوائس کو اس راستے کے استعمال کی اجازت ہے یا نہیں؛ ایپ طے کرتی ہے کہ پہنچا ہوا سرور وہی ہے جس کی توقع تھی۔ دونوں کا جواب الگ الگ دیں اور ڈیزائن آسان ہو جائے گا۔
دو دروازے، دو سوال
نیٹ ورک میں داخلہ کلائنٹ سے متعلق ہے: کیا یہ ڈیوائس رجسٹر ہے، کیا اس کی اسناد درست ہیں، اور کیا پالیسی اسے اس راستے پر جانے دیتی ہے؟ ایپ کا اعتماد سرور سے متعلق ہے: کیا کنکشن ایسی سروس تک پہنچا جس کی شناخت ایپ قبول کرتی ہے؟ یہ جواب مختلف نظاموں سے آتے ہیں، مختلف وجوہات سے ناکام ہوتے ہیں، اور مختلف ٹیمیں انہیں درست کرتی ہیں۔ VPN ہینڈ شیک کامیاب ہو سکتا ہے جبکہ ایپ ساتھی کے پیچھے موجود میعاد ختم شدہ سرٹیفکیٹ سے بات کر رہی ہو۔ مکمل طور پر پن شدہ ایپ بھی کسی کی پہنچ سے باہر رہ سکتی ہے، کیونکہ ڈیوائس کبھی نیٹ ورک پر آیا ہی نہیں۔
دونوں جڑتے ہیں۔ ایک کو ہٹانا ایک کنٹرول ہٹانا ہے؛ دوسرے کو شامل کرنا اس کی جگہ نہیں لیتا۔
پن دراصل کیا محدود کرتا ہے
پن ایپ کی قبول کردہ سرور شناختوں کا مجموعہ تنگ کرتا ہے، عام طور پر کسی ذخیرے کی ضمانت والی ہر زنجیر پر اعتماد کرنے کے بجائے عوامی کلید یا سرٹیفکیٹ ہیش کا نام لیتا ہے۔ یہ عام تصدیق کے اوپر رکھی گئی حد ہے، اس کا متبادل نہیں۔ عام تصدیق بتاتی ہے کہ زنجیر بنیادی طور پر قابل اعتماد ہے یا نہیں؛ پن بتاتا ہے کہ کیا یہی وہ زنجیر ہے جس کی اس ایپ کو توقع ہے۔ جو عمل درآمد پہلا قدم چھوڑ دیتا ہے اس نے سلامتی نہیں پائی، صرف نیاپن پایا۔
پن کی جانے والی چیز پلیٹ فارم کے لحاظ سے مختلف ہوتی ہے، اس لیے اکیلا لفظ بہت کم بتاتا ہے۔ ایک مصنوعات کے اعتماد ذخیرے سے ہیش نقل کرنا اور موبائل ایپ میں اسے وہی چیز سمجھنا ایک عام اور خاموش غلطی ہے۔
پلیٹ فارم پر پننگ ایک ترتیب ہے، پالیسی نہیں
Android اپنی نیٹ ورک سلامتی ترتیب کے ذریعے پننگ دیتا ہے، جہاں پن سیٹ عوامی کلید کے ڈائجسٹ رکھتا ہے اور زنجیر میں ان میں سے کم از کم ایک ہونا چاہیے۔ وہ فائل ہر ایپ کے لیے الگ ہے اور جان بوجھ کر بلڈ تبدیلی مانگتی ہے۔ iOS کے پاس اس کے برابر مینی فیسٹ طریقہ نہیں، اس لیے وہاں پننگ ایپ کے اپنے اعتماد جانچ کوڈ میں رہتی ہے۔
چونکہ طریقہ مختلف ہے، ضرورت ہر پلیٹ فارم کے لیے لکھنی ہوگی۔ جو پالیسی پلیٹ فارم کا نام لیے بغیر کہتی ہے کہ سرٹیفکیٹ پن کریں، وہ قابل عمل نہیں۔
گردش طے کرتی ہے کہ پن زندہ رہے گا یا نہیں
مشکل حصہ پہلی ریلیز نہیں، اس کے بعد سرٹیفکیٹ کی تجدید ہے۔ سخت اعتماد پالیسی جائز نئی کلید کو اتنی ہی مضبوطی سے مسترد کرتی ہے جتنی حملہ آور کی کلید کو۔
دو طریقے گردش کو قابل برداشت بناتے ہیں: ایک بیک اپ پن جس پر ضرورت سے پہلے ہی اعتماد ہو، اور پن سیٹ پر میعاد ختم ہونے کی تاریخ تاکہ نفاذ ختم ہو جائے، ایپ بند نہ ہو۔ دونوں پالیسی فیصلے ہیں، اور خاص طور پر میعاد کا ختم ہونا سلامتی میں جان بوجھ کر کمی ہے، کوئی بے ضرر ٹائمر نہیں۔ نام لیں کہ ایپ کی بلڈ، TLS کا آخری نقطہ اور سرٹیفکیٹ کی تجدید کون کنٹرول کرتا ہے، اور انہیں ایک ہی تبدیلی کے عمل میں لائیں۔ اگر وہ تین مختلف ٹیمیں ہیں، تو پن بالآخر ایسا تعطل پیدا کرے گا جس کی کسی نے منصوبہ بندی نہیں کی تھی۔
گمشدہ ڈیوائس تیسرا مسئلہ ہے
VPN اسناد منسوخ کرنا ضروری نہیں کہ ایپ کا سیشن ختم کر دے، اور سرور پن کسی اور کے ہاتھ میں موجود فون کے بارے میں کچھ نہیں کرتا۔ ڈیوائس لاک، اسناد کا ذخیرہ، سیشن کی عمر اور دور سے منسوخی الگ مالکان والے الگ فیصلے ہیں۔ انہیں پننگ بحث میں لپیٹ دینا یقینی بناتا ہے کہ ان میں سے کسی کا ڈیزائن نہیں ہوگا۔
جو ایک تعلق آپ دیکھتے ہیں اس کے بجائے چار تعلقات جانچیں: مطلوبہ سرور اور کارروائی، ایسا اکاؤنٹ جسے مسترد کیا جانا چاہیے، ایسی سرور شناخت جسے رد کیا جانا چاہیے، اور منصوبہ بند گردش۔ کام کرنے والا VPN صرف پہلے کی مشق کرتا ہے۔ لکھیں کہ ہر جانچ نے کیا ثابت کیا، کیونکہ اگلا شخص سمجھے گا کہ سبز سرنگ کا مطلب چاروں کا پاس ہونا ہے۔