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 സുരക്ഷാ കോൺഫിഗറേഷൻ ഗൈഡ് പ്ലാറ്റ്ഫോമിന്റെ സ്വതവേയുള്ള മൂല്യങ്ങളും ഏത് ഘടകങ്ങൾ നയം പാലിക്കുന്നു എന്നതും പട്ടികപ്പെടുത്തുന്നു, നിങ്ങളുടെ കോൺഫിഗറേഷൻ ഒട്ടും എന്തെങ്കിലും ചെയ്യുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നത് ഈ ഭാഗമാണ്.