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