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 ಭದ್ರತಾ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾರ್ಗದರ್ಶಿ ವೇದಿಕೆಯ ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಮತ್ತು ಯಾವ ಘಟಕಗಳು ನೀತಿಯನ್ನು ಗೌರವಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಸಂಪೂರ್ಣವಾಗಿ ಏನಾದರೂ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಈ ಭಾಗವೇ.