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