Android-VPN versus appmachtigingen: wat de waarschuwing betekent

Twee Android-vensters worden voortdurend door elkaar gehaald: de VPN-toestemmingsvraag en de machtigingsverzoeken die een app voor je gegevens doet. De eerste geeft een netwerkpositie weg, de plek waar pakketten kunnen worden gelezen en herschreven. De tweede geeft opgeslagen inhoud weg die Android app voor app beschermt. Ze als één ding behandelen overdrijft ofwel wat een tunnel kan zien, ofwel onderschat ernstig wat een vasthoudende app hierna zal vragen.

Wat het toestemmingsvenster werkelijk weggeeft

Een app die VpnService implementeert en BIND_VPN_SERVICE declareert, vraagt het systeem om de VPN van het apparaat te worden. Na goedkeuring maakt het framework een tun-interface aan en geeft de app daarvoor een bestandsdescriptor. Alles wat de app daarna doet, stroomt door die descriptor: hij leest IP-pakketten naar buiten, beslist wat ermee gebeurt en schrijft pakketten weer naar binnen.

De reikwijdte van die interface is uitdrukkelijk. Routes bepalen welke bestemmingen worden onderschept, en addAllowedApplication of addDisallowedApplication bepaalt welke apps hem voeden. Een VPN per app die twee apps vermeldt, ziet de rest van het apparaat niet.

Dat is een toekenning op pakketniveau, niet op gegevensniveau. De dienst ziet de bytes die een app aan de netwerkstack afgeeft, geadresseerd aan een bestemming. Hij krijgt geen toegang tot de privéopslag van de verzendende app, de databasebestanden of het ontsleutelde geheugen. Bestanden die een app in zijn eigen sandbox heeft opgeslagen, blijven precies even moeilijk leesbaar als voorheen.

Waar het pakketbeeld ophoudt

TLS doet binnen de tunnel nog steeds zijn werk, omdat de handshake tussen de app en de server loopt en niet tussen de app en de VPN. De VPN geeft versleutelde tekst door die hij zonder de sessiesleutels niet kan ontsleutelen. Daarom onthult een tunnel alleen niet de inhoud van een HTTPS-pagina of een beveiligde mailsessie.

De metadata rond de versleutelde tekst is een ander verhaal, en hier vallen de meeste zelfverzekerde beweringen uiteen. Bestemmings-IP, poort, pakketgroottes en timing zijn allemaal zichtbaar, plus de servernaam in de TLS ClientHello, die normaal gesproken zelfs onder TLS 1.3 onversleuteld wordt verzonden. Encrypted Client Hello verandert dat, maar het is niet universeel. Gewone DNS lekt namen net zo gemakkelijk wanneer query's onversleuteld naar buiten gaan.

Oudere of verkeerd geconfigureerde protocollen geven meer weg. Gewone HTTP, IMAP zonder TLS en een reeks spel- en IoT-protocollen leggen hun payload bloot aan alles wat de tun-descriptor heeft.

De machtigingen die er nooit bij komen

Een VPN goedkeuren keurt geen contacten, sms'jes, foto's of de mediabibliotheek goed. Dat zijn afzonderlijke machtigingen tijdens runtime, elk met een eigen venster en een eigen intrekkingsroute op de instellingenpagina van de app. Een VPN-client die je belgeschiedenis wil, moet erom vragen zoals elke andere app, en je kunt weigeren terwijl je de tunnel houdt.

Certificaatinstallatie is degene waar je op moet letten, want het lijkt deel van de VPN-installatie en is dat niet. Een gebruikers-CA in het referentiearchief installeren verandert welke certificaten Android accepteert, en sinds Android 7.0 negeert een app die op API 24 of nieuwer is gericht, door de gebruiker toegevoegde CA's, tenzij de netwerkbeveiligingsconfiguratie die met een gebruikersvertrouwensanker accepteert. Een client die op een CA staat, doet mogelijk legitieme bedrijfsinterceptie, of vraagt iets wat het VPN-venster nooit heeft genoemd.

Toegang via toegankelijkheid staat nog verder weg. Een dienst met toegankelijkheid ingeschakeld kan de scherminhoud van andere apps lezen, wat geen enkele positie op pakketniveau biedt.

Lokaal filter of gateway op afstand

Dezelfde API dekt twee producten die een verschillend vertrouwensniveau verdienen. Een firewall of advertentieblokkeerder op het apparaat neemt de tun-descriptor en beantwoordt het verkeer lokaal, zonder het ooit naar een server te sturen die hij zelf beheert. Een echte tunnel stuurt die pakketten door naar een gateway elders, en die beheerder ziet dezelfde metadata vanaf de andere kant en beslist ook wat er terugkomt.

Een praktische manier om ze te onderscheiden is je openbare adres controleren met de VPN aan en uit, en kijken of de melding een extern eindpunt noemt. Als het adres nooit verandert, draait het verkeer waarschijnlijk op het apparaat zelf in het rond.

Beide gevallen zijn nog steeds een pakketpositie. Het verschil is wie er verder bij de uitgang staat.

Controleer wat je hebt goedgekeurd

Open Instellingen, dan Netwerk en internet, dan VPN, en lees de vermelding in plaats van het pictogram in de statusbalk. Always-on VPN en Verbindingen blokkeren zonder VPN zijn apparaatinstellingen die de interface levend houden en lekken afsnijden; ze verruimen niets. Vanaf hetzelfde scherm kun je het profiel vergeten en de toekenning intrekken.

Loop daarna de andere machtigingen na. App-info toont welke runtime-toekenningen de client heeft, en de beveiligingsinstellingen tonen of tegelijkertijd een gebruikerscertificaat is geïnstalleerd. Beide kunnen afzonderlijk worden verwijderd.

De vraag die het antwoorden waard is, is smal: welke pakketten komen deze dienst binnen, waar gaan ze heen en wat bewaart de implementatie. Al het overige in het venster is ruis. De VpnService-referentie is de gezaghebbende lijst van wat de interface blootlegt.