- Dans certaines combinaisons d’apps et d’états sur Android, des requêtes DNS peuvent sortir du tunnel VPN ; Mullvad estime que la cause est un bug de l’OS Android plutôt qu’un problème de l’app VPN
- La fuite peut se produire lors de brèves phases de transition, par exemple lorsque le VPN est activé mais que le serveur DNS est vide, lors de la reconfiguration du tunnel, ou lorsque l’app VPN est forcée à s’arrêter ou plante
- L’impact se concentre sur les apps qui appellent directement
getaddrinfo; aucune fuite n’a été observée dans les apps qui utilisent uniquement l’API Android DnsResolver - Le problème n’est pas entièrement bloqué même avec Always-on VPN et « Block connections without VPN » activés, et il a été confirmé sur plusieurs versions, dont Android 14
- Mullvad prévoit de configurer temporairement un faux serveur DNS afin d’atténuer certaines situations, mais les fuites pendant une reconnexion sont difficiles à bloquer complètement sans correctif de l’OS
Conditions des fuites DNS sur Android
- Le 22 avril, Mullvad a confirmé, via le signalement d’un utilisateur Reddit, qu’une fuite DNS pouvait se produire lorsque le VPN était désactivé puis réactivé alors que « Block connections without VPN » était activé
- Une enquête interne a fait apparaître d’autres scénarios dans lesquels l’OS Android peut envoyer du trafic DNS hors du VPN
- Lorsque le VPN est actif mais qu’aucun serveur DNS n’est configuré
- Pendant que l’app VPN reconfigure le tunnel
- Pendant un court laps de temps lorsque l’app VPN est forcée à s’arrêter ou plante
- Ce comportement n’est pas celui attendu de l’OS Android et doit être corrigé à un niveau supérieur de l’OS
Apps concernées et chemins de résolution de noms
- La fuite semble se produire dans les apps qui appellent directement la fonction C
getaddrinfopour résoudre les noms de domaine - Aucune fuite n’a été observée dans les apps qui utilisent uniquement l’API Android DnsResolver
- Le navigateur Chrome est un exemple d’app pouvant utiliser directement
getaddrinfo- L’emplacement du code Chromium correspondant est également public
- L’utilisation de
getaddrinfon’est pas en soi incorrecte ; pour protéger tous les utilisateurs d’Android, une solution au niveau de l’OS est nécessaire
Limites d’Always-on VPN et du paramètre de blocage
- Les fuites confirmées se produisent indépendamment de l’activation de Always-on VPN et de « Block connections without VPN »
- Lorsque « Block connections without VPN » est activé, rien d’autre que le trafic WireGuard chiffré ne devrait sortir de l’appareil, mais lors de la reproduction, du DNS en clair a été observé au niveau du routeur
- Mullvad estime que ce paramètre ne respecte pas son nom ni son comportement documenté, et qu’il présente plusieurs défauts
- Le trafic DNS peut fuiter dans les conditions ci-dessus
- Comme déjà signalé auparavant, le trafic de vérification de connexion continue également de fuiter
Atténuation temporaire dans l’app Mullvad et problèmes restants
- L’app Mullvad ne configure actuellement pas de serveur DNS en état de blocage
- Si la configuration du tunnel échoue d’une manière irrécupérable, l’app passe en état de blocage
- Dans cet état, elle empêche le trafic de sortir de l’appareil, mais l’absence de serveur DNS peut créer les conditions d’une fuite
- Pour contourner le bug de l’OS, Mullvad prévoit pour le moment de répondre en configurant un faux serveur DNS, et compte publier prochainement une version incluant ce correctif
- Les fuites qui se produisent pendant la reconnexion du tunnel sont plus difficiles à atténuer au niveau de l’app
- Mullvad cherche une solution
- Il pourrait être possible de réduire le nombre de reconfigurations du tunnel, mais Mullvad ne pense pas, à ce stade, pouvoir bloquer complètement cette fuite
- Mullvad a signalé le problème et des propositions d’amélioration à Google
Observations reproduites avec WireGuard et Chrome
- Le deuxième scénario, une fuite lors d’un changement de configuration du tunnel VPN, peut être reproduit avec l’app WireGuard et Chrome
- WireGuard est utilisé comme cas de référence pour l’implémentation VPN d’Android
- Mullvad estime qu’il est probablement possible de le reproduire avec d’autres apps VPN Android
- Chrome est utilisé pour déclencher la fuite, car son utilisation de
getaddrinfoa été confirmée
- La procédure de reproduction comprend les éléments suivants
- Télécharger spam_get_requests.html
- Installer l’app WireGuard et Chrome
- Importer wg1.conf et wg2.conf dans WireGuard
- Activer le tunnel wg1 dans WireGuard et autoriser les permissions VPN
- Dans les paramètres VPN d’Android, activer Always-on VPN et « Block connections without VPN » pour WireGuard
- Sur le routeur, démarrer une capture avec
tcpdump -i <INTERFACE> host <IP of android device> - Ouvrir WireGuard et Chrome en écran partagé, exécuter
spam_get_requests.htmldans Chrome, puis alterner entre wg1 et wg2 dans WireGuard
- Sur le routeur, des requêtes d’enregistrement A allant de l’appareil Android vers le port 53 du routeur OpenWrt, ainsi que des réponses NXDomain, ont été observées
- Les fuites DNS peuvent servir à déduire la localisation approximative de l’utilisateur ou les sites et services consultés, ce qui peut avoir un impact important sur la vie privée
- Selon le modèle de menace, il peut être nécessaire, pour des usages sensibles, d’éviter Android ou d’appliquer d’autres mesures d’atténuation contre les fuites
- Les utilisateurs de l’app Mullvad doivent la maintenir à jour, car une atténuation partielle pourrait y être incluse
1 commentaires
Avis sur Hacker News
Je n’utilise pas Mullvad, mais j’en viens vraiment à les respecter. La description du problème, la solution de contournement à court terme, les solutions de contournement potentielles que d’autres peuvent utiliser, et même ce qu’il faut corriger dans Android : tout est très dense en informations et bien structuré
L’inconvénient, dans mon cas, c’est que le ping est nettement plus élevé qu’avec quad9 ou cloudflare
J’ai mis dans ce fil une méthode de blocage des pubs au niveau DNS et des informations concernant cloudflare : https://news.ycombinator.com/item?id=40056162
Ils ont rapidement résolu le problème de paiement, et j’ai aussi reçu une réponse détaillée sur iptables, avec les avantages et inconvénients de plusieurs solutions. En un mot : excellent
Je suis le développeur de rethinkdns
À propos de l’affirmation selon laquelle « ces problèmes doivent être résolus dans l’OS pour protéger tous les utilisateurs d’Android, quelle que soit l’application utilisée », le réseau paranoïaque d’Android a toujours prévu des exceptions pour les applications système et OEM, donc aussi pour les applications Google
La plupart de ces corrections de bugs ne changeront probablement pas cette hypothèse fondamentale. Voir le code associé : https://github.com/celzero/rethink-app/issues/224
Quant à la partie disant que « les fuites pendant la reconnexion du tunnel sont plus difficiles à atténuer côté application ; nous cherchons encore une solution », Android prend en charge, lors d’une reconfiguration, une transition sans interruption entre deux interfaces TUN. C’est délicat à implémenter correctement, mais possible
C’est un problème de longue date sur Android. Même si l’on veut n’utiliser qu’un serveur DNS interne, Android bascule sur le réseau cellulaire et utilise ce DNS s’il estime que c’est nécessaire ou souhaitable
Récemment, j’ai observé le débogage adb pour comprendre pourquoi/quand la connexion sans fil se coupait, et au final, si quelque chose n’est pas vu ou interprété correctement pendant la vérification de connectivité, il active les données cellulaires et essaie par ce biais
C’est particulièrement frustrant lorsque j’utilise des enregistrements DNS qui n’existent qu’en interne et que le téléphone se comporte de manière arbitraire. L’appareil est connecté au Wi-Fi qui fournit le serveur DNS interne contenant ces enregistrements, mais pour une raison propre à Android, il essaie de les résoudre depuis l’extérieur
Je ne sais pas ce qu’il en est chez Apple, mais vu qu’ils essaient en gros de proxifier jusqu’au DNS via DoH à travers leur VPN « privacy », j’ai du mal à imaginer que ce soit mieux quand on utilise quelque chose qui pourrait être vu comme un produit concurrent, et l’on sait aussi comment Apple traite ce genre de produits
Pour un exemple concret, voir ce bloqueur de pubs à l’échelle du système : https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
Le seul problème que j’ai rencontré, c’est que l’appareil indiquait ne pas avoir Internet alors qu’il était connecté à un point d’accès Wi‑Fi fonctionnel. En réalité, cela marchait, mais pour l’icône de la barre d’état et d’autres usages du code système interne, il semblait vérifier le bon fonctionnement d’Internet via des serveurs Google
Si la confidentialité vous importe, mieux vaut éviter Android, et probablement faire attention à la technologie en général
Il y a quelques années, lorsque je testais plusieurs configurations VPN pour un projet, je plaçais souvent un pare-feu MikroTik entre l’ordinateur et le routeur principal. Le seul objectif était de bloquer tout trafic dont la destination n’était pas l’adresse IP du serveur VPN auquel le PC voulait se connecter
Cette méthode fonctionnait très bien pour garantir qu’aucun trafic ne sorte du PC en dehors du chemin vers le serveur VPN. L’adresse IP du serveur VPN utilisé change rarement, et même si elle change, elle est facile à modifier dans le pare-feu MikroTik
Si l’on ne connaît pas l’IP du serveur, ou si elle change, on peut aussi bloquer tout trafic qui n’utilise pas la paire port/protocole employée par le serveur VPN. Par exemple, selon le type de VPN, on peut jeter tout trafic dont la destination n’est pas UDP 1194
Les routeurs MikroTik disposent aussi d’un petit outil appelé torch, qui permet de voir le trafic rapidement et facilement, et ils prennent également en charge la capture de paquets. Les prix vont de 30 à 3000 dollars, il n’y a pas de licence logicielle, et si l’on sait s’en servir, c’est extrêmement puissant et efficace
À strictement parler, un vrai slug est un pare-feu transparent de couche 2 sans adresse IP définie, mais inutile de pinailler sur ce détail ici
https://john.kozubik.com/pub/NetworkSlug/tip.html
Le filtrage sortant basé sur les adresses et ports source/destination est un concept de base des pare-feu et une configuration standard sur toutes les plateformes de pare-feu/routage. Le routage basé sur des politiques, qui filtre au niveau de la passerelle, relève du même principe : https://en.wikipedia.org/wiki/Policy-based_routing
En général, seuls les produits grand public ou semi-professionnels autorisent par défaut tout le trafic sortant. Dans cette configuration, je me demande ce qu’était le « routeur principal ». Un équipement fourni par le FAI ?
Ce serait bien de pouvoir intercaler un pare-feu entre les apps du téléphone et le modem.
Le problème DNS d’Android tient au fait qu’on ne peut pas définir son propre serveur DNS IPv6 sur cette plateforme. Il change dès qu’il y a la moindre modification sur le Wi‑Fi.
Même sur un Android rooté, il n’existe pas d’app empêchant le système d’exploitation de le modifier.
Si vous utilisez un routeur qui distribue en permanence des adresses IPv6 sans permettre de désactiver cela, vous êtes tout simplement coincé.
Je ne sais même pas s’il est possible d’installer un pare-feu derrière ce routeur pour supprimer le serveur DNS IPv6 annoncé par celui-ci.
Si les fuites de requêtes DNS vous préoccupent, il faut de toute façon utiliser DoT ou DoH.
Je me demande si la même chose se produit aussi avec le partage de connexion Wi‑Fi. Si l’on utilise un VPN sur un ordinateur portable connecté via le Wi‑Fi du téléphone, est-ce que ça fuit de la même manière ?
La configuration la plus sûre semble être de couper les données mobiles du téléphone et d’emporter avec soi un hotspot OpenWRT qui gère le VPN en amont du téléphone.
Le « VPN toujours actif » ne peut être configuré que sur des appareils en mode « supervised » via une solution MDM d’une organisation approuvée par Apple. Il faut une demande documentée et un appel téléphonique avec un employé actuel.
Sinon, il faut utiliser l’app Apple Configurator sur Mac pour créer un profil de configuration contenant la clé « always-on VPN ».
Les notifications étaient aussi souvent retardées.
Si ce n’est pas mon réseau, mieux vaut ne pas s’y connecter directement sans routeur mobile.
The Grugq avait créé un outil à cette fin il y a dix ans. Malheureusement, il n’est plus maintenu aujourd’hui : https://github.com/grugq/portal
Cela faisait partie d’une présentation sur la sécurité opérationnelle pour hackers, et si vous vous intéressez aux cas de plusieurs hackers célèbres ou tristement célèbres qui se croyaient en sécurité mais ont fini par se faire prendre, ça vaut le coup d’œil : https://www.youtube.com/watch?v=9XaYdCdwiWU
Un système sans accès root n’est, par définition, pas sûr. Android et iOS sont ridicules à cet égard.
Je plains les enfants qui ont grandi, ou grandiront, avec pour seuls ordinateurs des appareils principalement conçus pour la consommation de médias et la collecte de données privées.
https://en.wikipedia.org/wiki/PinePhone_Pro
Si vous pouvez récupérer une copie de ma clé privée SSH sur l’un de ces appareils, je vous donne 100 000 dollars en liquide, sans poser de questions.
Cette définition n’a aucun sens et n’est utile ni pour raisonner ni pour communiquer.
« Bloquer les connexions sans VPN » s’avère à peu près aussi fiable que ma maîtrise de soi dans un buffet. Sauf erreur de ma part, ce genre de fuite DNS peut révéler pas mal de choses, jusqu’aux sites visités et à la localisation, ce qui ruine l’objectif même du VPN.
Comme Android peut laisser fuiter des informations DNS même quand le VPN est activé, si la confidentialité vous importe vraiment, mieux vaut envisager autre chose qu’Android, ou sortir les tâches sensibles du téléphone.
Il m’arrive de me demander si ce genre de « bug » n’est pas placé là intentionnellement. D’autant plus quand on sait que les grands groupes tech ont collaboré avec diverses agences de renseignement.
Ce n’est pas la première fois que j’entends parler de ce type de bug sur Android, et j’ai désormais du mal à croire qu’autant de bugs soient apparus « involontairement ».
Je soupçonnais plus ou moins depuis longtemps que ce serait le cas. Même avec un VPN activé sur Android, les MMS et la messagerie vocale visuelle continuent de fonctionner.
Les deux nécessitent parfois un accès mobile direct, faute de quoi ils sont refusés. Ils peuvent n’être disponibles que sur le réseau mobile, ou être refusés si la requête ne provient pas de l’intérieur du réseau mobile. Je soupçonne que c’est pareil pour VoLTE. Avec un VPN, ces fonctions peuvent se mettre à dysfonctionner.
Sous Mobile Linux, on s’en rend compte parce que l’activation du VPN casse toutes ces fonctionnalités.
Il ne semble pas y avoir de moyen évident de corriger cela sur Android sans casser beaucoup de fonctionnalités attendues.
Ayant déjà bataillé avec l’équipe d’assistance avancée d’AT&T sur iOS avec un VPN activé à cause de problèmes liés à VVS, je peux confirmer que ce problème ne se limite pas à Android
Des bearers différents peuvent avoir des priorités/QCI différentes, autrement dit une qualité de service différente. Sur un réseau LTE congestionné, VoLTE devrait offrir une meilleure expérience que la VoIP sur un bearer de priorité plus faible