Android tətbiqlərində açıq mətni VPN-dən asılı olmadan bloklayın

Android-də açıq mətnin bloklanması adlanan iki tamamilə fərqli şey var. Biri tətbiqin içindəki siyasətdir və öz şəbəkə yığınına adi HTTP-ni rədd etməyi əmr edir. Digəri cihaz səviyyəsində quruluşdur və telefondakı hər şeyi birdən qorumağa çalışır, adətən trafiki VPN-dən keçirməklə. Onlar fərqli problemləri həll edir və ikincisi birincini düzəldə bilməz: tunel telefonla çıxış arasındakı seqmenti qoruyur, HTTP danışan tətbiq isə o çıxışın o tərəfindəki hər şeylə yenə HTTP danışır.

Bir ad altında iki problem

Birinci problem faydalı yükdür: tətbiq etimad məlumatlarını və ya tokenləri ucdan-uca şifrələnməmiş sorğuya yazır, ona görə onu görə bilən hər hop onu oxuya bilər. İkincisi yoldur: tətbiq tamamilə qaydasında ola bilər, siz yenə də yerli Wi-Fi operatorunun hara qoşulduğunu bilməməsini istəyirsiniz. VPN ikincini həll edir və yalnız ikincini.

Bu fərq düzəlişin sahibini müəyyən edir. Faydalı yük tətbiqi yayanındır, çünki hansı URL-in çağırıldığını və sertifikatın yoxlanılıb-yoxlanılmadığını yalnız o kod müəyyən edir. Yol cihazın və ya şəbəkənindir, çünki söhbət paketlərin nə daşıdığından deyil, hara getdiyindən gedir.

Birinci yol: nəzarət etdiyiniz tətbiq

Tətbiqi siz yayırsınızsa, düzəliş nəqliyyat qərarı və onu tətbiq edən siyasətdir. Hər son nöqtəni HTTPS-ə yönəldin, host adı və sertifikat yoxlamasını açıq saxlayın və adi HTTP ehtiyat variantını bir konfiqurasiya bayrağı uzaqlıqda saxlamaq əvəzinə silin. Yönləndirmə burada kömək etmir: 301 alan HTTP sorğusu başlıqlarını və gövdəsini artıq açıq göndərmişdir, ona görə etimad məlumatları heç vaxt yönləndirmənin onları qoruyacağı fərziyyəsi ilə getməməlidir.

Android 7.0 və sonrasında siyasəti Network Security Configuration ifadə edir. Aşağıdakı fayl ən kiçik faydalı versiyadır: domenə xas istisna başqa cür deməzsə, hər yerdə açıq mətni rədd edir.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Bu resursa manifestdən istinad edin, sonra yayımdan əvvəl artıq mövcud olan istisnaları oxuyun. Köhnə sazlama domeni və ya ödəniş provayderi SDK qeydi qorumaq istədiyiniz host üçün açıq mətnə səssizcə yenidən icazə verə bilər.

İki versiya detalını bilməyə dəyər. API 28 və ya daha yenisini hədəfləyən tətbiqlər artıq standart olaraq açıq mətni rədd edir, ona görə hələ adi HTTP danışan tətbiq ya daha köhnə API səviyyəsini hədəfləyir, ya da haradasa istisnası var. Şəbəkə təhlükəsizliyi konfiqurasiyası mövcud olduqda isə köhnə android:usesCleartextTraffic manifest atributu məsələni artıq həll etmir, buna görə də həmin bayrağı dəyişmək bəzən heç nə etmir kimi görünür.

İkinci yol: nəzarət etmədiyiniz tətbiq

Quraşdırılmış üçüncü tərəf tətbiqi üçün onun təhlükəsizlik konfiqurasiyasını istifadəçi parametri ilə yenidən yaza bilməzsiniz. Real variantlar məhsulun öz təhlükəsiz bağlantı nizamlayıcıları, artıq TLS istifadə edən dəstəklənən alternativ və ya cihazın nə işlədə biləcəyini məhdudlaşdıran idarə olunan cihaz siyasətidir. Bunlar fərqli öhdəliklərdir və yalnız üçüncüsü donanma səviyyəsində miqyaslanır.

Şəbəkə qaydaları göründüyündən zəif əvəzləyicilərdir. Yalnız 443 portuna icazə vermək autentifikasiyalı TLS-i tətbiq etmir, çünki çoxlu açıq mətn protokolu o porta köçürülə bilər, 80 portunu bloklamaq isə digər portlardakı açıq mətni əhatə etmir. Brauzerin yalnız-HTTPS rejimi də həmin brauzerlə məhduddur, eyni telefonda ayrı poçt və ya söhbət tətbiqi ilə deyil.

Trafiki şifrələnmiş göstərmək üçün müdaxilə sertifikatı quraşdırmaq etimad dəyişikliyidir, düzəliş deyil. O, tətbiqin server autentifikasiyasını sizinlə əvəz edir və sertifikatları əvvəldən yoxlamayan tətbiqi bununla düzəltmir; siz yalnız axını kimin oxuya biləcəyini dəyişmisiniz.

VPN harada kömək edir, harada etmir

Tələb yerli şəbəkənin bağlantı haqqında heç nə bilməməsi və ya tətbiqin başqa cür çata bilmədiyi özəl xidmətə çatması olduqda tunel düzgün alətdir. HTTP müştərisini HTTPS danışdırmaq üçün isə səhv alətdir, çünki sorğu tuneldən girdiyi kimi çıxır.

Android praktik bir məhdudiyyət əlavə edir: platforma eyni anda bir VPN xidməti işlədir. O yeri tutan yerli filtrləmə tətbiqi həqiqətən ehtiyac duyduğunuz uzaq tunellə rəqabət edir və aralarında keçid tətbiq səviyyəsində deyil, cihaz səviyyəsində əməliyyatdır. Bu tək yer faydalı yük siyasətini tətbiqə qoymaq və tuneli yol üçün saxlamaq üçün yaxşı səbəbdir.

İkisinin üst-üstə düşdüyü yeganə hal sizin də idarə etdiyiniz özəl serverdir. Orada tunel protokol hələ açıq mətn olsa da yolu özəl edə bilər, bu məruz qalmanı azaldır, lakin faydalı yükün nə olduğunu dəyişmir. Buna riskin azaldılması kimi yanaşın, məlumatların şifrələnməsi kimi deyil.

Bloklanmış deməzdən əvvəl nəyi test etmək lazımdır

İnsanları təəccübləndirən standartdan başlayın: API 28 və ya daha yenisini hədəfləyən tətbiq artıq açıq mətni rədd etməlidir, ona görə standartı təkrarlayan konfiqurasiya əlavə etməzdən əvvəl hədəf səviyyəsini yoxlayın. Sonra uğursuzluq halını qəsdən test edin: adi HTTP hostuna sorğu ehtiyat variantla səssizcə uğur qazanmaq əvəzinə uğursuz olmalıdır.

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

Uğur halı üçün HTTPS çağırışının real sertifikat zəncirini yoxladığını və etibarsız sertifikatlı proksinin tolere edilmədən rədd edildiyini təsdiqləyin. Hər hansı sertifikatla uğur qazanan əl sıxma nəqliyyat təhlükəsizliyi barədə heç nə sübut etməmişdir.

Üçüncü tərəf tətbiqi üçün həqiqətən tətbiq edə biləcəyiniz sərhədi yazın — idarə olunan cihaz siyasəti, şəbəkə qaydası və ya heç nə — və bunu qəbul meyarlarında qeyd edin. Android təhlükəsizlik konfiqurasiyası bələdçisi platformanın standartlarını və hansı komponentlərin siyasətə riayət etdiyini sadalayır; konfiqurasiyanızın ümumiyyətlə nəsə etdiyini məhz bu hissə həll edir.