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 सुरक्षा कॉन्फिगरेशन मार्गदर्शक प्लॅटफॉर्मचे डीफॉल्ट आणि कोणते घटक धोरणाचे पालन करतात ते सूचीबद्ध करते, आणि तुमचे कॉन्फिगरेशन अजिबात काही करते का हे ठरवणारा हाच भाग आहे.