VPN'e güvenmeden Android uygulamalarında düz metni engelleyin

Android'de düz metni engellemek denilen iki tamamen farklı şey var. Biri, uygulamanın içindeki kendi ağ yığınına sade HTTP'yi reddetmesini emreden bir ilkedir. Diğeri, telefonda her şeyi aynı anda korumaya çalışan cihaz düzeyinde bir düzenlemedir; genellikle trafiği bir VPN üzerinden geçirir. Farklı sorunları çözerler ve ikincisi birinciyi düzeltemez: tünel telefon ile çıkış arasındaki parçayı korur, oysa HTTP konuşan bir uygulama o çıkışın ötesindeki her şeyle hâlâ HTTP konuşur.

Tek ad altında iki sorun

İlk sorun yüktür: uygulama kimlik bilgilerini veya jetonları uçtan uca şifrelenmemiş bir isteğe yazar, böylece onu görebilen her atlama okuyabilir. İkincisi yoldur: uygulama tamamen doğru olabilir ve siz yine de yerel Wi-Fi işletmecisinin nereye bağlandığı hakkında hiçbir şey öğrenmemesini istersiniz. VPN ikincisini ve yalnızca ikincisini ele alır.

Bu ayrım düzeltmenin sahibini belirler. Yük uygulamayı dağıtanındır, çünkü hangi URL'nin çağrıldığını ve sertifikanın doğrulanıp doğrulanmadığını yalnızca o kod belirler. Yol cihazın veya ağın sorunudur, çünkü mesele paketlerin nereye gittiğidir, ne içerdiği değil.

Birinci yol: kontrol ettiğiniz uygulama

Uygulamayı siz dağıtıyorsanız, düzeltme bir taşıma kararı ve onu uygulayan bir ilkedir. Her uç noktayı HTTPS'e yönlendirin, ana makine adı ve sertifika doğrulamasını açık tutun ve sade HTTP'ye geri dönüş yolunu bir yapılandırma bayrağı uzakta bırakmak yerine silin. Yönlendirme burada yardımcı olmaz: 301 alan bir HTTP isteği başlıklarını ve gövdesini zaten açık olarak göndermiştir, bu nedenle kimlik bilgileri yönlendirmenin onları koruyacağı varsayımıyla asla yola çıkmamalıdır.

Android 7.0 ve sonrasında ilkeyi Network Security Configuration ifade eder. Aşağıdaki dosya en küçük kullanışlı sürümdür: alana özgü bir istisna aksini söylemedikçe düz metni her yerde reddeder.

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

Bu kaynağa manifestodan başvurun, sonra dağıtmadan önce zaten var olan istisnaları okuyun. Eski bir hata ayıklama alan adı veya ödeme sağlayıcısının SDK girdisi, korumaya çalıştığınız ana makine için düz metni sessizce yeniden izin verebilir.

Sürümle ilgili iki ayrıntıyı bilmekte yarar var. API 28 veya daha yenisini hedefleyen uygulamalar düz metni zaten varsayılan olarak reddeder, yani hâlâ sade HTTP konuşan bir uygulama ya daha eski bir API düzeyini hedefliyordur ya da bir yerde istisnası vardır. Ve bir ağ güvenliği yapılandırması varsa, eski android:usesCleartextTraffic manifest niteliği bu soruyu artık belirlemez; bu yüzden o bayrağı değiştirmek bazen hiçbir şey yapmıyormuş gibi görünür.

İkinci yol: kontrol etmediğiniz uygulama

Kurulu bir üçüncü taraf uygulama için güvenlik yapılandırmasını bir kullanıcı ayarıyla yeniden yazamazsınız. Gerçekçi seçenekler ürünün kendi güvenli bağlantı denetimleri, zaten TLS kullanan bakımlı bir alternatif veya cihazın neleri çalıştırabileceğini sınırlayan yönetilen cihaz ilkesidir. Bunlar farklı taahhütlerdir ve yalnızca üçüncüsü bir cihaz filosuna ölçeklenir.

Ağ kuralları göründüklerinden daha zayıf vekillerdir. Yalnızca 443 portuna izin vermek kimliği doğrulanmış TLS'i zorunlu kılmaz, çünkü birçok düz metin protokolü o porta taşınabilir ve 80 portunu engellemek diğer portlardaki düz metni kapsamaz. Tarayıcının yalnızca-HTTPS modu da o tarayıcıyla sınırlıdır, aynı telefondaki ayrı bir e-posta veya sohbet uygulamasıyla değil.

Trafiğin şifreli görünmesi için bir araya girme sertifikası kurmak bir güven değişikliğidir, düzeltme değil. Uygulamanın sunucu kimlik doğrulamasını sizinkiyle değiştirir ve sertifikaları baştan doğrulamayan bir uygulama bununla düzelmez; yalnızca akışı kimin okuyabildiğini taşıdınız.

VPN nerede yardımcı olur, nerede olmaz

Tünel, gereksinim yerel ağın bağlantı hakkında hiçbir şey öğrenmemesi veya uygulamanın başka türlü ulaşamadığı özel bir hizmete ulaşması olduğunda doğru araçtır. Bir HTTP istemcisine HTTPS konuşturmak için yanlış araçtır, çünkü istek tünelden tam olarak girdiği gibi çıkar.

Android pratik bir kısıtlama ekler: platform aynı anda yalnızca bir VPN hizmeti çalıştırır. O yeri alan yerel bir filtreleme uygulaması gerçekten ihtiyacınız olan uzak tünelle rekabet eder ve ikisi arasında geçiş yapmak uygulama düzeyinde değil cihaz düzeyinde bir işlemdir. O tek yer, yük ilkesini uygulamada tutup tüneli yol için saklamak adına iyi bir nedendir.

İkisinin örtüştüğü tek durum, sizin de işlettiğiniz özel bir sunucudur. Orada tünel, protokol hâlâ düz metin olsa bile yolu özel hale getirebilir; bu, maruziyeti azaltır ama yükün ne olduğunu değiştirmez. Bunu risk azaltma olarak görün, verinin şifrelenmesi olarak değil.

Buna engellendi demeden önce ne test edilmeli

İnsanları şaşırtan varsayılanla başlayın: API 28 veya daha yenisini hedefleyen bir uygulama düz metni zaten reddetmelidir, bu nedenle bir varsayılanı çoğaltan yapılandırma eklemeden önce hedef düzeyi kontrol edin. Ardından başarısızlık durumunu bilerek test edin: sade bir HTTP ana makinesine istek, bir geri dönüşle sessizce başarılı olmak yerine başarısız olmalıdır.

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

Başarı durumu için, HTTPS çağrısının gerçek bir sertifika zincirini doğruladığını ve güvenilmeyen sertifikaya sahip bir proxy'nin tolere edilmek yerine reddedildiğini doğrulayın. Herhangi bir sertifikaya karşı başarılı olan bir el sıkışma, taşıma güvenliği hakkında hiçbir şey kanıtlamamıştır.

Üçüncü taraf bir uygulama için gerçekten uygulayabileceğiniz sınırı yazın; yönetilen cihaz ilkesi, ağ kuralı ya da hiçbiri olabilir, ve bunu kabul ölçütlerinde söyleyin. Android güvenlik yapılandırması kılavuzu platformun varsayılanlarını ve hangi bileşenlerin ilkeye uyduğunu listeler ve yapılandırmanızın herhangi bir şey yapıp yapmadığını belirleyen kısım tam da burasıdır.