Блакуйце адкрыты тэкст у праграмах Android без апораў на VPN

Дзве зусім розныя рэчы называюць блакаваннем адкрытага тэксту на Android. Адна — гэта палітыка ўнутры праграмы, якая загадвае ўласнаму сеткаваму стэку адмаўляцца ад звычайнага HTTP. Другая — гэта ўладкаванне на ўзроўні прылады, якое спрабуе абараніць усё на тэлефоне адразу, звычайна праз кіраванне трафікам праз VPN. Яны вырашаюць розныя праблемы, і другая не можа выправіць першую: тунель абараняе адрэзак паміж тэлефонам і выхадам, а праграма, якая гаворыць HTTP, усё роўна гаворыць HTTP з тым, што знаходзіцца за гэтым выхадам.

Дзве праблемы пад адной назвай

Першая праблема — карысная нагрузка: праграма запісвае ўліковыя дадзеныя ці токены ў запыт, які не шыфруецца ад канца да канца, таму кожны вузел, які яго бачыць, можа прачытаць. Другая — шлях: праграма можа быць цалкам паслухмянай, а вы ўсё роўна хочаце, каб мясцовы аператар Wi-Fi не даведаўся, куды яна падключаецца. VPN адрасаваны другой і толькі другой.

Гэтае размежаванне вызначае ўладальніка выпраўлення. Нагрузка належыць таму, хто выпускае праграму, бо толькі гэты код вырашае, які URL выклікаецца і ці правяраецца сертыфікат. Шлях належыць прыладзе ці сетцы, бо гаворка пра тое, куды ідуць пакеты, а не што яны ўтрымліваюць.

Першы шлях: праграма, якую вы кантралюеце

Калі вы выпускаеце праграму, выпраўленне — гэта рашэнне пра транспарт плюс палітыка, якая яго патрабуе. Накіруйце ўсе канчатковыя пункты на HTTPS, пакіньце праверку імя хоста і сертыфіката ўключанай і выдаліце запасны варыянт са звычайным HTTP, а не пакідайце яго на адлегласці аднаго сцяжка канфігурацыі. Перанакіраванне тут не дапамагае: HTTP-запыт, які атрымлівае 301, ужо адаслаў свае загалоўкі і цела ў адкрытым выглядзе, таму ўліковыя дадзеныя не павінны ісці з здагадкай, што перанакіраванне іх абароніць.

На 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 пералічвае прадвызначэнні платформы і тое, якія кампаненты слухаюцца палітыкі; менавіта гэтая частка вырашае, ці робіць ваша канфігурацыя наогул хоць што-небудзь.