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 భద్రతా కాన్ఫిగరేషన్ మార్గదర్శిని ప్లాట్‌ఫారమ్ డిఫాల్ట్‌లను మరియు ఏ భాగాలు విధానాన్ని గౌరవిస్తాయో జాబితా చేస్తుంది, మరియు మీ కాన్ఫిగరేషన్ అసలు ఏమైనా చేస్తుందా అనేది ఈ భాగమే నిర్ణయిస్తుంది.