Блокирайте открит текст в приложения за 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 изброява подразбиранията на платформата и кои компоненти спазват политиката, а това е частта, която решава дали вашата конфигурация прави изобщо нещо.