Ce qu’un pare-feu d’entreprise peut voir à l’intérieur d’un VPN, et ce qu’il ne peut pas

Le même portable atteint le VPN depuis chez lui et ne peut pas se connecter depuis le bureau, donc quelqu’un doit lire le trafic. Bloquer et lire sont deux pouvoirs distincts, et seul le second exige un point sur le chemin plus un certificat auquel le client fait confiance. Un intermédiaire qui jette votre poignée de main n’a rien appris de ce que vous auriez envoyé. Décider auquel des deux vous avez affaire, c’est tout le travail.

Bloquer et lire sont deux pouvoirs différents

Un refus est bon marché et bruyant : la socket s’ouvre et rien ne répond, ou un reset arrive aussitôt. Rien de tout cela n’implique une inspection, car aucune charge utile n’a franchi le câble.

Lire exige un point de terminaison qui met fin à la protection, se prouve par un certificat et ouvre une nouvelle connexion vers l’avant. Ce point doit se trouver sur le chemin et être approuvé par le client. Un pare-feu qui ne fait que transférer des paquets n’a ni position ni accréditation.

Ce que l’enveloppe livre gratuitement

Chaque paquet du tunnel a un extérieur, et cet extérieur doit être routable. Cela signifie deux adresses, un protocole, un port et une longueur, plus le minutage et le volume. N’importe quel routeur traite déjà ces champs, et un NAT réécrit l’adresse et le port pour garder sa table de correspondance cohérente. La charge reste scellée, donc l’observation s’arrête au fait qu’un tunnel existe entre deux hôtes.

Un nom d’hôte n’en fait pas partie. Les sites fuient par d’autres portes, et la plus large est le DNS : si le portable interroge encore le résolveur local, les noms apparaissent en clair.

Le minutage et le volume méritent du respect sans être exagérés. Octets par minute peuvent montrer qu’un transfert important commence à 14:20 ; ils ne peuvent pas montrer quel fichier a bougé. C’est une révélation réelle sur le comportement, et une autre catégorie que la lecture du contenu.

L’interception TLS exige une racine à laquelle vous faites déjà confiance

Un appareil d’inspection ne casse pas TLS ; il y met fin. Le client reçoit en réponse un certificat d’une racine que l’organisation possède, et une seconde connexion part vers la vraie destination. Le client l’accepte parce que cette racine figure dans son magasin de confiance, et c’est pourquoi un portable géré n’affiche aucun avertissement. La cryptographie n’a jamais été vaincue ; le point de terminaison a été déplacé.

C’est aussi pourquoi le dispositif laisse des preuves. L’émetteur de la chaîne présentée appartient à l’organisation et non à une AC publique, et un client peut le voir sans outillage particulier. Une chaîne qui se termine sur une racine interne est la signature de l’interception, pas un dysfonctionnement.

Pourquoi un canal VPN n’est pas une session HTTPS

Un canal de données VPN ne donne pas une telle prise à un inspecteur. IKEv2 et WireGuard exécutent leurs propres poignées de main et calendriers de clés, sans TLS à terminer, tandis qu’OpenVPN emprunte TLS pour son canal de contrôle sous une forme modifiée avant de protéger les données à sa façon. Un proxy conçu pour HTTPS ne reconnaît pas cette session comme quelque chose qu’il peut analyser.

Un appareil qui ne peut pas analyser une session peut malgré tout la jeter. Voilà pourquoi le blocage de VPN ressemble généralement à un délai d’attente et non à un avertissement de certificat, et pourquoi une exception ne change rien.

Le vérifier depuis votre propre machine

Commencez par la chaîne que présente le site. Les détails du site dans le navigateur montrent l’émetteur, et la ligne de commande rapporte la même chose sans le résumé :

openssl s_client -connect example.com:443 -servername example.com

Séparez ensuite une poignée de main refusée du trafic interne filtré à l’aide de compteurs. Journalisez le port de transport avant toute règle de rejet et lisez-les après la tentative :

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

Aucune ligne de journal sur la socket externe signifie que la poignée de main n’est jamais partie, donc le chemin refuse le tunnel. Une poignée de main aboutie avec seulement quelques destinations en échec signifie que le tunnel fonctionne et que la politique intérieure non. Aucun des deux résultats n’a exigé de lire un octet de charge.

La lecture qui a réellement lieu se situe aux bords : un tunnel divisé confie le HTTPS interne à un proxy d’entreprise, et un concentrateur détenu par l’employeur expose tout à la sortie. Quoi que vous trouviez, ne désactivez pas la vérification des certificats pour forcer une connexion, car ce contrôle est la seule chose qui sépare l’inspection d’un attaquant.