Ce que le réseau local voit encore à travers votre VPN

Trois observateurs se fondent en une seule question chaque fois que quelqu’un demande si un VPN cache son trafic : le réseau auquel il est rattaché, la machine entre ses mains et l’opérateur du tunnel. Chacun apprend quelque chose de différent, et le tunnel modifie chacune de ces vues d’une manière différente. Il est utile de travailler dans l’autre sens et de partir de l’affirmation avancée, car c’est l’affirmation qui doit résister à l’examen. Décidez de l’affirmation dont vous avez besoin, puis comparez les outils à elle.

Première affirmation : personne ne peut lire le trafic

Commencez par l’affirmation la plus étroite : la charge utile reste illisible. Un observateur passif sur le chemin ne peut pas voir à l’intérieur d’une session TLS, donc le tunnel ajoute peu à un site qui utilise déjà HTTPS et n’ajoute rien contre les deux extrémités. Celui qui brise cette affirmation est celui qui contrôle l’appareil, car un mandataire d’inspection termine la connexion et la signe à nouveau avec une racine à laquelle la machine fait déjà confiance. C’est pourquoi le cadenas apparaît encore tandis que la chaîne de certificats porte le nom de l’organisation qui a installé la racine.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

Sur macOS, ce pipeline imprime une ligne de sujet pour chaque certificat du trousseau de la machine, sans ouvrir de fenêtre, et sous Windows certutil -store Root énumère le même magasin que certlm.msc affiche graphiquement. Une racine appartenant à une école, à un employeur ou à un produit de sécurité réseau est l’entrée à rechercher. En trouver une prouve seulement que l’interception est possible, pas qu’elle a lieu.

Ce que vous pouvez y faire est une question de politique plutôt que de technique. Retirer un profil ou une racine d’inspection d’un matériel qui ne vous appartient pas enfreint normalement l’accord d’usage acceptable, et le système de gestion a tendance à le remarquer et à le réappliquer, si bien qu’exiger que le propriétaire de l’appareil ne lise pas votre trafic demande un autre appareil plutôt qu’un autre réglage.

Deuxième affirmation : personne ne voit où vous allez

La destination est l’affirmation la plus difficile, car deux divulgations ont lieu avant qu’une page se charge. Une requête part vers le résolveur que le système est configuré à utiliser, et la réponse est visible pour le réseau qui la transporte. Puis la poignée de main TLS transporte le nom du serveur demandé en clair, sauf si Encrypted Client Hello est pris en charge aux deux extrémités. Aucune des deux divulgations n’implique de déchiffrement, donc le tunnel n’a d’effet sur aucune.

resolvectl status | grep -A2 "Link"
nslookup example.com

Quel résolveur est réellement utilisé décide de l’exposition, et cela se mesure plutôt que se discute. Sous Linux, resolvectl status imprime les serveurs DNS par liaison, et sa sortie vous dit si c’est le résolveur du site ou celui qui est imposé qui répond. Windows répond à la même question avec nslookup example.com, dont le premier bloc de sortie est le serveur DNS qui a répondu.

Lorsque l’ordinateur portable interroge le résolveur du site avant que le tunnel monte, ou que le profil arrive sans serveur de remplacement si bien que l’ancien reste utilisé, l’administrateur collecte encore des noms d’hôtes sans rien déchiffrer. Le DNS chiffré du navigateur contourne le résolveur imposé ou bien est bloqué tout à fait et échoue en fermé. L’opérateur de sortie voit les mêmes noms de son côté. Changer de résolveur n’éloigne donc pas cette divulgation du fournisseur du tunnel.

Troisième affirmation : personne ne sait que vous vous êtes connecté

La troisième affirmation est celle qu’un tunnel ne peut pas soutenir, car les paquets traversent toujours le réseau local. Ce réseau apprend l’adresse du point de sortie, le volume approximatif, le moment et l’existence d’une session chiffrée de longue durée, ce qui suffit à bloquer, à limiter ou simplement à remarquer. Un pare-feu qui ne peut pas lire un paquet peut encore refuser de le laisser passer. Être surveillé n’est pas la même chose que n’être surveillé par personne : vous avez déplacé l’observateur, vous ne l’avez pas supprimé.

Le tunnel divisé, et toute application qui ignore la route imposée, produisent des flux hors du tunnel qui ressemblent exactement à avant. Ce sont ces flux qu’un observateur attentif remarque en premier, et la table de routage du client montre quelles destinations sont exclues.

L’opérateur à l’autre bout détient l’image miroir de cette vue : adresse de sortie, moment, volume et généralement les noms des sites. Votre fournisseur devient la partie qui a le point de vue, ce qui est un autre marché que l’invisibilité. Choisir un fournisseur en qui vous avez confiance est une vraie décision ; qualifier le résultat de non observé ne l’est pas.

Décidez de l’affirmation dont vous avez besoin

Écrivez l’exigence en une ligne avant de toucher à un client : cacher le contenu, cacher les destinations ou cacher si vous vous êtes connecté. Le contenu est déjà traité par HTTPS avec le tunnel, tandis que les destinations exigent un résolveur et un chemin qui contournent entièrement l’équipement du site.

La troisième exigence est la gênante, car quelque chose reste visiblement connecté quelque part, chiffré ou non. Aucun réglage du client ne change cela. Si l’exigence et la politique se séparent, cet écart relève d’une conversation avec qui possède la politique, non d’une option du client. La personne qui peut y répondre est celle qui a écrit la politique.