VPN Android face aux autorisations des applications : ce que signifie l'avertissement

Deux fenêtres d'Android sont sans cesse confondues : l'invite de consentement VPN et les demandes d'autorisation qu'une application formule pour vos données. La première cède une position réseau, l'endroit où les paquets peuvent être lus et réécrits. La seconde cède un contenu stocké qu'Android protège application par application. Les traiter comme une seule chose soit exagère ce qu'un tunnel peut voir, soit sous-estime gravement ce qu'une application déterminée demandera ensuite.

Ce que la fenêtre de consentement cède réellement

Une application qui implémente VpnService et déclare BIND_VPN_SERVICE demande au système de devenir le VPN de l'appareil. Après approbation, le framework crée une interface tun et fournit à l'application un descripteur de fichier pour celle-ci. Tout ce que l'application fait ensuite passe par ce descripteur : elle en lit les paquets IP, décide quoi en faire et réécrit des paquets vers l'intérieur.

La portée de cette interface est explicite. Les routes décident quelles destinations sont capturées, et addAllowedApplication ou addDisallowedApplication décide quelles applications l'alimentent. Un VPN par application qui liste deux applications ne voit pas le reste de l'appareil.

Il s'agit d'une autorisation au niveau des paquets, pas au niveau des données. Le service voit les octets qu'une application remet à la pile réseau, adressés vers une destination. Il n'obtient aucune prise sur le stockage privé de l'application émettrice, sur ses fichiers de base de données ni sur sa mémoire déchiffrée. Les fichiers qu'une application a enregistrés dans son propre bac à sable restent exactement aussi difficiles à lire qu'auparavant.

Où s'arrête la vue des paquets

TLS fait toujours son travail à l'intérieur du tunnel, car la poignée de main se déroule entre l'application et le serveur, non entre l'application et le VPN. Le VPN transmet un texte chiffré qu'il ne peut pas déchiffrer sans les clés de session. C'est pourquoi un tunnel seul ne révèle pas le contenu d'une page HTTPS ni d'une session de messagerie protégée.

Les métadonnées autour du texte chiffré sont une autre histoire, et c'est ici que la plupart des affirmations assurées s'effondrent. L'IP de destination, le port, les tailles de paquets et le minutage sont tous visibles, ainsi que le nom du serveur dans le TLS ClientHello, qui est normalement envoyé en clair même sous TLS 1.3. Encrypted Client Hello change cela, mais ce n'est pas universel. Un DNS simple fuit les noms tout aussi facilement quand les requêtes sortent non chiffrées.

Les protocoles plus anciens ou mal configurés cèdent davantage. HTTP simple, IMAP sans TLS et plusieurs protocoles de jeux et d'objets connectés exposent leurs charges utiles à tout ce qui détient le descripteur tun.

Les autorisations qui ne viennent jamais avec

Approuver un VPN n'approuve ni les contacts, ni les SMS, ni les photos, ni la bibliothèque multimédia. Ce sont des autorisations d'exécution distinctes, chacune avec sa propre fenêtre et son propre chemin de révocation dans la page de paramètres de l'application. Un client VPN qui veut votre journal d'appels doit le demander comme n'importe quelle autre application, et vous pouvez refuser tout en gardant le tunnel.

L'installation de certificat est celle à surveiller, car elle ressemble à une partie de la configuration VPN sans en être une. Installer une AC utilisateur dans le magasin d'informations d'identification change les certificats qu'Android acceptera, et depuis Android 7.0 une application ciblant l'API 24 ou une version ultérieure ignore les AC ajoutées par l'utilisateur, sauf si sa configuration de sécurité réseau l'accepte avec une ancre de confiance utilisateur. Un client qui insiste sur une AC peut faire une interception d'entreprise légitime, ou demander quelque chose que la fenêtre VPN n'a jamais mentionné.

L'accès à l'accessibilité se situe encore plus loin. Un service avec l'accessibilité activée peut lire le contenu d'écran d'autres applications, ce qu'aucune position au niveau des paquets ne fournit.

Filtre local ou passerelle distante

La même API couvre deux produits qui méritent des niveaux de confiance différents. Un pare-feu ou un bloqueur de publicités sur l'appareil prend le descripteur tun et répond au trafic localement, sans jamais l'envoyer à un serveur qu'il exploite. Un véritable tunnel transmet ces paquets à une passerelle située ailleurs, et cet opérateur voit les mêmes métadonnées depuis l'autre extrémité tout en décidant de ce qui revient.

Un moyen pratique de les distinguer est de vérifier votre adresse publique avec le VPN activé puis désactivé, et de regarder si la notification nomme un point de terminaison distant. Si l'adresse ne change jamais, le trafic boucle probablement sur l'appareil lui-même.

Dans les deux cas, il s'agit toujours d'une position sur les paquets. La différence est qui d'autre se tient à la sortie.

Auditez ce que vous avez approuvé

Ouvrez Paramètres, puis Réseau et Internet, puis VPN, et lisez l'entrée plutôt que l'icône de la barre d'état. Le VPN toujours actif et Bloquer les connexions sans VPN sont des réglages d'appareil qui maintiennent l'interface en vie et coupent les fuites ; ils n'élargissent rien. Depuis le même écran, vous pouvez oublier le profil et révoquer l'autorisation.

Parcourez ensuite les autres autorisations. Les informations sur l'application montrent quelles autorisations d'exécution le client détient, et les paramètres de sécurité montrent si un certificat utilisateur a été installé en même temps. L'un comme l'autre peut être supprimé indépendamment.

La question qui mérite une réponse est étroite : quels paquets entrent dans ce service, où vont-ils et que conserve l'implémentation. Tout le reste dans la fenêtre n'est que bruit. La référence VpnService est la liste faisant autorité de ce que l'interface expose.