VPN پر انحصار کے بغیر Android ایپس میں صریح متن کو بلاک کریں

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

ایک نام کے نیچے دو مسائل

پہلا مسئلہ پے لوڈ ہے: ایپ اسناد یا ٹوکن ایسی درخواست میں لکھتی ہے جو سرے سے سرے تک خفیف نہیں، اس لیے ہر وہ ہاپ جو اسے دیکھ سکتا ہے پڑھ بھی سکتا ہے۔ دوسرا راستہ ہے: ایپ مکمل درست ہو سکتی ہے، اور آپ پھر بھی چاہتے ہیں کہ مقامی Wi-Fi آپریٹر کو اس بارے میں کچھ معلوم نہ ہو کہ یہ کہاں جڑتی ہے۔ VPN صرف دوسرے کو حل کرتا ہے۔

یہی فرق درستی کے مالک کا تعین کرتا ہے۔ پے لوڈ اس کا ہے جو ایپ فراہم کرتا ہے، کیونکہ کون سا URL کال ہوتا ہے اور سرٹیفکیٹ تصدیق ہوتا ہے یا نہیں یہ صرف وہی کوڈ طے کرتا ہے۔ راستہ ڈیوائس یا نیٹ ورک کا ہے، کیونکہ سوال یہ ہے کہ پیکٹ کہاں جاتے ہیں، یہ نہیں کہ ان میں کیا ہے۔

پہلا راستہ: وہ ایپ جو آپ کنٹرول کرتے ہیں

اگر آپ ایپ فراہم کرتے ہیں، تو درستی ایک ٹرانسپورٹ فیصلہ اور اسے نافذ کرنے والی پالیسی ہے۔ ہر اینڈ پوائنٹ کو HTTPS کی طرف موڑیں، ہوسٹ نام اور سرٹیفکیٹ کی تصدیق آن رکھیں، اور سادہ HTTP پر واپسی کا راستہ ایک کنفیگریشن جھنڈے کے فاصلے پر رکھنے کے بجائے حذف کر دیں۔ ری ڈائریکٹ یہاں مدد نہیں کرتا: 301 وصول کرنے والی HTTP درخواست اپنے ہیڈر اور باڈی پہلے ہی کھلے طور پر بھیج چکی ہے، اس لیے اسناد کو کبھی اس مفروضے پر سفر نہیں کرنا چاہیے کہ ری ڈائریکٹ ان کی حفاظت کرے گا۔

Android 7.0 اور اس کے بعد Network Security Configuration پالیسی کا اظہار کرتا ہے۔ نیچے دی گئی فائل سب سے چھوٹا مفید نسخہ ہے: یہ ہر جگہ صریح متن مسترد کرتی ہے جب تک کوئی ڈومین مخصوص استثنا کچھ اور نہ کہے۔

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

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

نسخے کی دو تفصیلیں جاننے کے قابل ہیں۔ API 28 یا نئے کو نشانہ بنانے والی ایپس پہلے ہی بطور طے شدہ صریح متن مسترد کرتی ہیں، اس لیے جو ایپ اب بھی سادہ HTTP بولتی ہے وہ یا تو پرانی API سطح کو نشانہ بناتی ہے یا کہیں استثنا رکھتی ہے۔ اور جب نیٹ ورک سیکیورٹی کنفیگ موجود ہو، تو پرانا android:usesCleartextTraffic مینی فیسٹ وصف اب یہ سوال طے نہیں کرتا، اسی لیے اس جھنڈے کو بدلنے سے کبھی کبھی کچھ نہ ہونے جیسا لگتا ہے۔

دوسرا راستہ: وہ ایپ جو آپ کنٹرول نہیں کرتے

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

نیٹ ورک قواعد دکھائی دینے سے کمزور متبادل ہیں۔ صرف پورٹ 443 کی اجازت تصدیق شدہ TLS نافذ نہیں کرتی، کیونکہ بہت سے صریح متن پروٹوکول اس پورٹ پر منتقل کیے جا سکتے ہیں، اور پورٹ 80 بلاک کرنا دوسرے پورٹس کے صریح متن کو نہیں ڈھکتا۔ براؤزر کا صرف-HTTPS موڈ بھی اسی براؤزر تک محدود ہے، اسی فون کی الگ میل یا چیٹ ایپ تک نہیں۔

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

VPN کہاں مدد کرتا ہے اور کہاں نہیں

ٹنل صحیح اوزار ہے جب ضرورت یہ ہو کہ مقامی نیٹ ورک کنکشن کے بارے میں کچھ نہ جانے، یا ایپ ایسی نجی خدمت تک پہنچے جہاں ورنہ نہیں پہنچ سکتی۔ HTTP کلائنٹ کو HTTPS بولوانے کے لیے یہ غلط اوزار ہے، کیونکہ درخواست ٹنل سے ویسے ہی نکلتی ہے جیسے داخل ہوئی تھی۔

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

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

بلاک کہنے سے پہلے کیا جانچیں

اس طے شدہ سے شروع کریں جو لوگوں کو حیران کرتا ہے: API 28 یا نئے کو نشانہ بنانے والی ایپ کو پہلے ہی صریح متن مسترد کرنا چاہیے، اس لیے طے شدہ کی نقل کرنے والی کنفیگریشن شامل کرنے سے پہلے ہدف سطح دیکھیں۔ پھر ناکامی کا معاملہ جان بوجھ کر جانچیں: سادہ HTTP ہوسٹ پر درخواست کو ناکام ہونا چاہیے، بیک اپ کے ذریعے خاموشی سے کامیاب نہیں۔

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

کامیابی کے معاملے میں تصدیق کریں کہ HTTPS کال حقیقی سرٹیفکیٹ زنجیر کی تصدیق کرتی ہے اور غیر معتبر سرٹیفکیٹ والا پراکسی برداشت کرنے کے بجائے مسترد ہوتا ہے۔ جو ہینڈ شیک کسی بھی سرٹیفکیٹ کے ساتھ کامیاب ہو وہ ٹرانسپورٹ سیکیورٹی کے بارے میں کچھ ثابت نہیں کرتا۔

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