Obfuscation et résistance au blocage : la course contre le DPI

Chiffrer un tunnel empêche de lire ce qu'il transporte, pas de savoir que c'est un tunnel. Dans un réseau qui filtre activement — pare-feu national, réseau d'entreprise strict —, l'enjeu devient de rendre le trafic VPN indistinguable d'un trafic ordinaire. Cette page décrit comment un dispositif d'inspection profonde (DPI) repère un VPN et les couches successives d'obfuscation, dans le prolongement du fonctionnement du tunnel décrit sur la page d'accueil.

Comment un DPI identifie un VPN

Plusieurs signaux se combinent. La signature du handshake d'abord : le premier paquet d'un protocole a une forme reconnaissable — un opcode caractéristique pour OpenVPN, un message initial de 148 octets d'un type précis pour WireGuard, des échanges sur les ports UDP 500 et 4500 pour IKE. L'analyse statistique ensuite : un tunnel VPN a une distribution de tailles de paquets et un rythme différents de ceux d'une navigation web, et cela se mesure même sans rien déchiffrer. Le port et le nom de domaine indiqué dans le handshake TLS (SNI) fournissent d'autres indices. Enfin, le sondage actif : quand un flux est suspect, le pare-feu ouvre lui-même une connexion vers le serveur pour voir s'il se comporte comme un serveur VPN ; si oui, il le classe et le bloque, parfois de façon permanente.

Niveau 1 : changer de port et de transport

La première contre-mesure, minimale, consiste à faire écouter le serveur sur le port 443 en TCP, celui du trafic HTTPS. Cela suffit contre un filtrage grossier qui se contente de bloquer les ports VPN habituels. Contre un DPI qui inspecte le contenu, c'est insuffisant : un handshake OpenVPN sur le port 443 reste un handshake OpenVPN.

Niveau 2 : les transports pluggables

Développés à l'origine pour le réseau Tor, les transports pluggables enveloppent le flux dans une couche qui supprime toute structure reconnaissable. Le plus répandu, obf4, transforme le trafic en une suite d'octets qui paraît aléatoire, sans handshake identifiable, et randomise la taille et le délai entre paquets pour brouiller l'analyse statistique. Il résiste bien au sondage actif car un client sans la bonne clé n'obtient aucune réponse exploitable. Son défaut : un flux « entièrement aléatoire » est lui-même une anomalie dans un réseau où le trafic normal est surtout du TLS, et certains censeurs bloquent désormais tout ce qui n'a pas l'air d'un protocole connu.

Niveau 3 : se cacher dans du TLS réel

Plutôt que de paraître aléatoire, on peut faire ressembler le trafic à une véritable session HTTPS. Le tunnel est alors encapsulé dans une connexion TLS complète, avec un vrai certificat et un vrai nom de domaine : de l'extérieur, cela ressemble à un navigateur qui consulte un site. Des outils génériques comme stunnel, ou les modes d'obfuscation propriétaires de certains clients, fonctionnent sur ce principe. C'est robuste, mais coûteux en surcharge : on empile TLS au-dessus du tunnel, qui est déjà chiffré.

Niveau 4 : imiter finement HTTPS ou QUIC

Les censeurs les plus avancés inspectent aussi la cohérence du TLS : ordre des extensions, comportement après le handshake, réaction au sondage. Les projets récents visent une imitation au plus près. Shadowsocks, conçu pour contourner le filtrage, se combine à des greffons qui l'encapsulent dans du WebSocket derrière un réseau de diffusion de contenu, de sorte que le trafic semble aller vers un grand hébergeur légitime. D'autres approches — Trojan, les variantes XTLS, ou les protocoles fondés sur QUIC comme Hysteria — cherchent à reproduire exactement la signature d'un client web courant, tout en gardant de bonnes performances. Ce sont des outils de contournement plus que des VPN au sens strict, mais la frontière est devenue floue.

Le domain fronting et son déclin

Une technique a longtemps compté : le domain fronting. Le client ouvrait une connexion TLS vers un grand hébergeur en indiquant, dans la partie visible du handshake, le nom d'un site anodin hébergé chez le même prestataire, puis demandait en réalité, dans la partie chiffrée, le vrai serveur de contournement. Pour le censeur, cela ressemblait à une visite d'un service majeur qu'il ne pouvait pas bloquer sans dommage collatéral. Les grands hébergeurs ont progressivement désactivé cette possibilité, et le chiffrement du nom de domaine dans le handshake — qui devait tout changer — se déploie lentement. Le domain fronting reste cité, mais n'est plus une solution fiable.

Ponts et adresses non publiées

Même le meilleur transport ne sert à rien si l'adresse du serveur figure sur une liste de blocage. D'où la notion de pont : un point d'entrée dont l'adresse n'est pas publiée et n'est distribuée qu'à la demande, par petits lots, pour ralentir son énumération par le censeur. Les services de contournement sérieux combinent transports obfusqués et distribution contrôlée d'adresses ; un fournisseur qui publie une liste fixe de serveurs sur son site les rend triviaux à bloquer en bloc.

Quoi activer, et quand

La règle est simple : n'activer l'obfuscation que lorsque le tunnel ordinaire est effectivement bloqué. Dans un réseau ouvert, elle n'apporte rien et dégrade la connexion. Face à un filtrage par port, changer de port suffit souvent. Face à un DPI qui inspecte le contenu, il faut un transport obfusqué ou une encapsulation TLS. Face à un dispositif national avec sondage actif, seule une combinaison — transport imitant HTTPS, adresses non publiées, mise à jour continue — tient dans la durée, et encore, de façon intermittente. Tester plusieurs modes et retenir le plus léger qui fonctionne est la bonne démarche.

Le coût de l'obfuscation

Chaque couche ajoutée a un prix. La surcharge d'en-tête augmente et réduit la MTU utile. La latence grimpe, surtout avec une encapsulation TCP-sur-TCP. La configuration se complexifie, et donc la surface d'erreur. Surtout, l'obfuscation ne renforce en rien la confidentialité : elle cache l'existence du tunnel, pas son contenu, qui reste protégé par la cryptographie du tunnel. Activer l'obfuscation dans un réseau qui ne filtre pas ne fait que ralentir la connexion sans aucun bénéfice.

Le cas de WireGuard

WireGuard est particulièrement facile à repérer : son premier paquet a une taille et un type fixes, et le protocole ne prévoit rien pour le déguiser. Il n'existe pas d'obfuscation native ; les solutions consistent à faire passer le tunnel WireGuard à l'intérieur d'une autre couche — un tunnel obfusqué, une session TLS, un transport de type Shadowsocks — ou à utiliser un dérivé conçu pour ajouter du remplissage et de l'aléa. C'est un compromis assumé du protocole : simplicité et performance d'un côté, discrétion nulle de l'autre.

Une course sans fin

Le filtrage et le contournement progressent en réaction l'un à l'autre. Les grands dispositifs nationaux — en Chine, en Iran, en Russie — combinent aujourd'hui listes de blocage, analyse statistique assistée par apprentissage automatique, sondage actif à grande échelle et blocage temporaire d'adresses entières lors d'événements sensibles. Aucune technique d'obfuscation n'est définitivement gagnante : une méthode efficace un trimestre peut être détectée le suivant. C'est pourquoi les fournisseurs sérieux dans ce domaine font tourner plusieurs transports en parallèle et les mettent à jour en continu.

Ce qu'il faut retenir

Un tunnel chiffré reste identifiable comme tunnel ; l'obfuscation vise à le rendre indistinguable d'un trafic banal, par couches successives allant du simple changement de port à l'imitation fine d'une session HTTPS. Elle coûte en performance et en complexité, n'améliore pas la confidentialité, et ne sert que face à un réseau filtrant. Le choix du transport de base est traité sur la page protocoles VPN comparés, et l'infrastructure qui héberge ces points de sortie sur la page architecture serveur.