Android VPN kontra alkalmazásengedélyek: mit jelent a figyelmeztetés

Két Android-párbeszédablakot kevernek össze újra és újra: a VPN-hozzájárulás kérését és azokat az engedélykéréseket, amelyeket egy alkalmazás az adataiért benyújt. Az első egy hálózati pozíciót ad át, azt a pontot, ahol a csomagok olvashatók és átírhatók. A második olyan tárolt tartalmat ad át, amelyet az Android alkalmazásonként véd. Ha egy dologként kezeljük őket, akkor vagy eltúlozzuk, mit láthat egy alagút, vagy súlyosan alábecsüljük, mit fog kérni legközelebb egy elszánt alkalmazás.

Mit ad át valójában a hozzájárulási párbeszédablak

Az az alkalmazás, amely megvalósítja a VpnService osztályt és deklarálja a BIND_VPN_SERVICE engedélyt, azt kéri a rendszertől, hogy váljon az eszköz VPN-jévé. Jóváhagyás után a keretrendszer létrehoz egy tun felületet, és fájlleírót ad hozzá az alkalmazásnak. Minden, amit az alkalmazás ezután tesz, ezen a leírón keresztül folyik: IP-csomagokat olvas ki belőle, eldönti, mit tegyen velük, és csomagokat ír vissza bele.

Ennek a felületnek a hatóköre egyértelmű. Az útvonalak döntik el, mely célpontok kerülnek befogásra, és a addAllowedApplication vagy a addDisallowedApplication dönti el, mely alkalmazások táplálják. Egy alkalmazásonkénti VPN, amely két alkalmazást sorol fel, nem látja az eszköz többi részét.

Ez csomagszintű engedély, nem adatszintű. A szolgáltatás azokat a bájtokat látja, amelyeket az alkalmazás a hálózati veremnek átad, egy célra címezve. Nem kap hozzáférést a küldő alkalmazás privát tárhelyéhez, adatbázisfájljaihoz vagy visszafejtett memóriájához. Azok a fájlok, amelyeket az alkalmazás a saját homokozójában mentett, pontosan ugyanolyan nehezen olvashatók, mint korábban.

Ahol a csomagokra vonatkozó nézet véget ér

A TLS továbbra is végzi a dolgát az alagúton belül, mert a kézfogás az alkalmazás és a kiszolgáló között zajlik, nem az alkalmazás és a VPN között. A VPN olyan titkosított szöveget továbbít, amelyet a munkamenetkulcsok nélkül nem tud visszafejteni. Ezért egy alagút önmagában nem tárja fel egy HTTPS-oldal vagy egy védett levelezési munkamenet tartalmát.

A titkosított szöveget körülvevő metaadatok más történet, és itt hullik szét a legtöbb magabiztos állítás. A cél IP-címe, a port, a csomagméretek és az időzítés mind látható, valamint a kiszolgáló neve a TLS ClientHello üzenetben, amelyet általában nyíltan küldenek még a TLS 1.3 alatt is. Az Encrypted Client Hello ezt megváltoztatja, de nem általános. A sima DNS ugyanolyan könnyen kiszivárogtatja a neveket, amikor a lekérdezések titkosítás nélkül mennek ki.

A régebbi vagy rosszul beállított protokollok többet adnak át. A sima HTTP, a TLS nélküli IMAP és számos játék- és IoT-protokoll feltárja a hasznos terhelését mindennek, aminek a tun leírója a birtokában van.

Az engedélyek, amelyek soha nem járnak vele

Egy VPN jóváhagyása nem hagyja jóvá a névjegyeket, az SMS-eket, a fényképeket vagy a médiatárat. Ezek külön futásidejű engedélyek, mindegyiknek saját párbeszédablaka és saját visszavonási útvonala van az alkalmazás beállításoldalán. Egy VPN-kliensnek, amely a híváslistáját akarja, úgy kell kérnie, mint bármely más alkalmazásnak, és Ön megtagadhatja, miközben megtartja az alagutat.

A tanúsítványtelepítés az, amire érdemes figyelni, mert a VPN beállításának részének tűnik, és nem az. A felhasználói hitelesítésszolgáltató hitelesítőadat-tárba telepítése megváltoztatja, hogy az Android mely tanúsítványokat fogadja el, és az Android 7.0 óta az API 24 vagy újabb szintet célzó alkalmazás figyelmen kívül hagyja a felhasználó által hozzáadott hitelesítésszolgáltatókat, kivéve ha a hálózati biztonsági konfigurációja felhasználói bizalmi horgonnyal ezt engedélyezi. Az a kliens, amely ragaszkodik egy hitelesítésszolgáltatóhoz, lehet, hogy jogszerű vállalati lehallgatást végez, de az is lehet, hogy olyasmit kér, amit a VPN párbeszédablaka soha nem említett.

A kisegítő lehetőségekhez való hozzáférés még távolabb van. Egy kisegítő lehetőségekkel engedélyezett szolgáltatás olvashatja más alkalmazások képernyőtartalmát, amit semmilyen csomagszintű pozíció nem biztosít.

Helyi szűrő vagy távoli átjáró

Ugyanaz az API két olyan terméket fed le, amelyek eltérő bizalmi szintet érdemelnek. Az eszközön lévő tűzfal vagy hirdetésblokkoló átveszi a tun leírót, és helyben válaszol a forgalomra, soha nem küldve azt az általa üzemeltetett kiszolgálóra. Egy valódi alagút továbbítja ezeket a csomagokat egy máshol lévő átjáróhoz, és az az üzemeltető ugyanazokat a metaadatokat látja a másik végéről, miközben azt is eldönti, mi jön vissza.

Gyakorlati módja a megkülönböztetésüknek, hogy ellenőrizzük a nyilvános címünket be- és kikapcsolt VPN mellett, és megnézzük, nevez-e meg az értesítés egy távoli végpontot. Ha a cím soha nem változik, a forgalom valószínűleg az eszközön belül köröz.

Mindkét eset továbbra is csomagszintű pozíció. A különbség az, hogy ki más áll a kijáratnál.

Vizsgálja felül, amit jóváhagyott

Nyissa meg a Beállításokat, majd a Hálózat és internet, majd a VPN pontot, és az állapotsor ikonja helyett a bejegyzést olvassa. Az Always-on VPN és a Kapcsolatok blokkolása VPN nélkül olyan eszközbeállítások, amelyek életben tartják a felületet és elvágják a szivárgásokat; semmit nem szélesítenek. Ugyanarról a képernyőről elfelejtheti a profilt, és visszavonhatja az engedélyt.

Utána járja körbe a többi engedélyt. Az alkalmazás adatai megmutatják, milyen futásidejű engedélyekkel rendelkezik a kliens, a Biztonság beállítások pedig azt, hogy telepítettek-e ugyanakkor felhasználói tanúsítványt. Bármelyik függetlenül eltávolítható.

A megválaszolásra érdemes kérdés szűk: mely csomagok lépnek be ebbe a szolgáltatásba, hová mennek, és mit tart meg a megvalósítás. Minden más zaj a párbeszédablakban. A VpnService-referencia a felület által feltárt dolgok mérvadó listája.