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 સિક્યોરિટી કોન્ફિગરેશન માર્ગદર્શિકા પ્લેટફોર્મના ડિફોલ્ટ અને કયા ઘટકો પોલિસીનું પાલન કરે છે તે સૂચિબદ્ધ કરે છે, અને એ જ ભાગ નક્કી કરે છે કે તમારું કોન્ફિગરેશન બિલકુલ કંઈ કરે છે કે નહીં.