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 सुरक्षा कॉन्फ़िगरेशन गाइड प्लेटफ़ॉर्म के डिफ़ॉल्ट और यह कि कौन-से घटक नीति का पालन करते हैं, सूचीबद्ध करता है, और यही हिस्सा तय करता है कि आपका कॉन्फ़िगरेशन बिल्कुल कुछ करता है या नहीं।