Pendant de nombreuses années, les ingénieurs réseau considéraient la compression des données et le chiffrement cryptographique comme une association évidente. Sur les liaisons internationales à fort trafic, la bande passante engendre des coûts opérationnels mesurables. Réduire la taille des paquets avant de leur appliquer un chiffrement symétrique semblait offrir un double avantage : économiser des mégaoctets sur les réseaux facturés au volume et accélérer les temps de transfert physique. Des protocoles historiques comme OpenVPN ont ainsi intégré des algorithmes de compression, notamment LZO et DEFLATE, directement dans leur chaîne de traitement de transport.

L'hypothèse semblait solide : des algorithmes de chiffrement symétrique modernes tels qu'AES-256-GCM ou ChaCha20-Poly1305 transforment les octets utiles en un flux binaire indiscernable d'un bruit blanc aléatoire. La croyance générale voulait qu'un observateur interceptant les paquets chiffrés sur le réseau ne puisse tirer aucune déduction sur le contenu en clair sous-jacent.

En 2018, le chercheur en sécurité Ahamed Nafeez a démontré l'invalidité de cette intuition en publiant l'attaque VORACLE (référencée sous la désignation CVE-2018-3972 et présentée aux conférences Black Hat USA et DEF CON 26). VORACLE a prouvé que la compression préalable au chiffrement crée un canal auxiliaire (side-channel) majeur fondé sur la longueur des paquets. En observant simplement les variations de taille des paquets chiffrés en transit, un espion placé sur le réseau peut reconstituer octet par octet des secrets confidentiels, tels que des cookies de session ou des jetons d'autorisation HTTP, sans casser le moindre algorithme de chiffrement.

+-------------------------------------------------------------------------+
|                  LE CANAL AUXILIAIRE DE COMPRESSION VORACLE             |
+-------------------------------------------------------------------------+
|                                                                         |
|  L'attaquant injecte une chaîne candidate ("Cookie: auth=a...")         |
|  dans le même flux que le secret de la victime ("Cookie: auth=s3cr3t..")|
|                                                                         |
|        Flux en clair (Secret de la victime + Données de l'attaquant)    |
|                                    │                                    |
|                                    ▼                                    |
|                        [ Moteur LZO / DEFLATE ]                         |
|                                    │                                    |
|    - Caractère erroné -> Aucune redondance -> Taille de sortie GRANDE   |
|    - Bon caractère    -> Pointeur LZ77 actif -> Taille de sortie RÉDUITE|
|                                    │                                    |
|                                    ▼                                    |
|                       [ Chiffrement AES / ChaCha ]                      |
|                                    │                                    |
|                                    ▼                                    |
|    Paquet chiffré sur le câble (La taille trahit la compression)        |
|                                    │                                    |
|    Mesure de la différence de taille -> Extraction de l'octet secret !  |
+-------------------------------------------------------------------------+

Théorie de l'information et origine de la fuite

Pour comprendre le fonctionnement de VORACLE, il convient d'analyser le comportement mathématique des algorithmes de compression sans perte. Les méthodes courantes telles que DEFLATE (RFC 1951) et LZO reposent sur deux briques élémentaires : le remplacement de chaînes par dictionnaire à fenêtre glissante LZ77 et le codage par préfixes de Huffman.

Avec LZ77, l'encodeur examine le flux d'octets entrant à la recherche de sous-chaînes redondantes. Lorsqu'une séquence d'octets se répète dans la fenêtre historique (généralement fixée à 32 Ko ou 64 Ko), l'algorithme substitue cette occurrence par un pointeur compact contenant deux informations :

  1. La distance : De combien d'octets en arrière se situe l'occurrence initiale.
  2. La longueur : Le nombre d'octets consécutifs identiques.

Si un paquet réseau contient deux séquences identiques de 16 caractères, la seconde est remplacée par un pointeur ne pesant que 2 ou 3 octets. La taille totale compressée diminue en proportion directe de la redondance interne du texte en clair.

C'est là que réside la contradiction avec la sécurité cryptographique. Les chiffrements symétriques modernes garantissent la confidentialité du contenu : un adversaire ne peut pas déterminer la valeur des bits chiffrés. En revanche, le chiffrement standard n'assure pas la confidentialité de la longueur.

Les chiffrements par flux (comme ChaCha20 ou AES en mode CTR) génèrent une suite chiffrante appliquée par opération XOR bit à bit. Une charge utile de 412 octets engendre exactement 412 octets de texte chiffré (auxquels s'ajoute une étiquette d'authentification). Quant aux chiffrements par blocs (AES-CBC), bien qu'ils imposent un alignement sur des frontières de 16 octets, la diminution d'une taille compressée franchit régulièrement ces frontières, laissant fuiter des variations par paliers de 16 octets.

Dès lors que la compression précède le chiffrement, la longueur du paquet chiffré devient une fonction mathématique directe de la redondance du texte en clair.

Déroulement pratique d'une attaque VORACLE

La vulnérabilité VORACLE a spécifiquement ciblé les tunnels OpenVPN configurés avec la compression active (comp-lzo yes ou la directive compress). L'attaque suit le modèle de l'attaque adaptative à texte clair choisi (adaptive chosen-plaintext attack) :

1. Positionnement sur le chemin réseau

L'attaquant s'établit en position d'intermédiaire sur la liaison de la victime : borne Wi-Fi publique compromise, routeur local manipulé ou sonde sur le réseau d'un fournisseur d'accès. Comme le trafic entre dans un tunnel VPN chiffré, l'attaquant ne peut pas lire directement la charge utile.

2. Injection de texte clair sous contrôle

L'adversaire pousse la victime à charger une page Web sous son contrôle, ou injecte un script dans une connexion HTTP non chiffrée consultée par l'utilisateur. Ce code JavaScript émet des requêtes HTTP multi-origines répétées vers un service cible (par exemple, un portail d'entreprise ou une interface bancaire).

Le navigateur de la victime émettant ces requêtes, il y attache automatiquement les cookies de session confidentiels de l'utilisateur dans les en-têtes HTTP. Parallèlement, le script de l'attaquant contrôle les paramètres d'URL, injectant des chaînes de test candidates dans le même flux de requête.

3. L'oracle de compression en action

Le système d'exploitation transmet la requête HTTP combinée à la carte réseau virtuelle du VPN. Le logiciel VPN compresse l'intégralité de la charge utile avant de la soumettre au moteur de chiffrement :

Structure du texte clair combiné :
[GET /api/user?probe=CHAINE_TEST HTTP/1.1\r\n]  <-- Contrôlé par l'attaquant
[Cookie: auth_token=7a8b9c0d1e2f3a4b\r\n]       <-- Jeton secret de la victime

Si la chaîne candidate injectée dans l'URL coïncide avec les premiers caractères du cookie de session secret, le compresseur LZ77 détecte la répétition d'octets. Il remplace ces caractères par un pointeur court, ce qui réduit immédiatement la taille globale du flux compressé de plusieurs octets.

Si la chaîne candidate est incorrecte, aucune répétition n'est trouvée et la taille du paquet compressé demeure inchangée.

4. Reconstitution caractère par caractère

L'attaquant observe la longueur des datagrammes UDP ou paquets TCP chiffrés transmis depuis l'appareil de la victime vers la passerelle VPN. Dès qu'une diminution de taille survient pour un caractère donné, l'attaquant sait qu'il a identifié l'octet correct.

En déplaçant sa fenêtre de test caractère après caractère, l'attaquant peut reconstituer un cookie de session complet ou un jeton de sécurité en quelques milliers de requêtes automatisées, souvent en moins de deux minutes.

Fil conducteur historique : de CRIME à VORACLE

VORACLE ne constitue pas une anomalie isolée, mais le prolongement logique des attaques par canal auxiliaire de compression sur les différentes couches du modèle réseau :

Vulnérabilité Année Couche ciblée Protocole visé Mesure de remédiation
CRIME (RFC 7540 §10.6) 2012 Transport / Session Compression au niveau TLS Désactivation définitive de la compression TLS dans les navigateurs
TIME 2013 Application Compression des réponses HTTP Remplissage aléatoire des réponses, limitation de débit
BREACH 2013 Application Corps HTTP (gzip/deflate) Masquage des jetons dynamiques, isolation des données
VORACLE (CVE-2018-3972) 2018 Réseau / Tunnel Tunnel VPN (OpenVPN LZO) Suppression de la compression dans les configurations de tunnel

À la suite de la publication de l'attaque CRIME par Julius Rizzo et Thai Duong en 2012, l'IETF a tranché sans ambiguïté : la norme RFC 7540 (HTTP/2) a formellement banni la compression au niveau TLS. Dès lors que des secrets d'authentification et des données influencées par l'utilisateur cohabitent dans une session compressée, le risque est inhérent.

Pendant longtemps, le secteur des VPN a présumé qu'opérer au niveau de la couche réseau (paquets IP) protégeait de ces mécanismes applicatifs. VORACLE a prouvé que lorsque des flux de niveaux de confiance distincts partagent un tunnel compressé, la fuite par canal auxiliaire opère avec la même efficacité.

Les raisons du refus délibéré de la compression par WireGuard

Lors de la conception du protocole WireGuard, Jason Donenfeld a expressément choisi d'exclure toute forme de compression de la charge utile.

Les protocoles VPN d'entreprise traditionnels ont accumulé une complexité logicielle considérable : négociation dynamique de clés, multiplicité de suites cryptographiques obsolètes et modules de compression. WireGuard applique une vision opposée : une stricte sobriété cryptographique et une surface d'attaque minimale.

Ce refus repose sur trois impératifs techniques :

  1. Élimination des fuites par la taille des paquets : Sans compression, la taille du texte en clair correspond directement à l'encapsulation réseau. Un observateur ne dispose d'aucun retour d'information pour monter une attaque à texte clair choisi.
  2. Déterminisme et sûreté de la mémoire : Les bibliothèques de compression comme zlib ou LZO intègrent des automates complexes manipulant des allocations dynamiques en mémoire tampon. Historiquement, elles ont souffert de vulnérabilités de corruption de mémoire. WireGuard s'exécute dans l'espace noyau avec une empreinte mémoire fixe et prévisible.
  3. Suppression de la gigue de calcul : Le coût de calcul d'une compression dépend de l'entropie des données. Les flux chiffrés (vidéos HTTPS, archives compressées) ne se compressent pas, obligeant le processeur à analyser vainement des fenêtres glissantes sans aucun gain de taille, provoquant des pointes de latence sous forte charge.

Architecture RiceGuard : zéro compression et remplissage uniforme

Dans les infrastructures de communication modernes, la compression des paquets est désormais considérée comme un risque injustifié. Au sein de VPNRice, le moteur de réseau RiceGuard applique une interdiction absolue de toute compression sur l'ensemble des passerelles et des applications clientes.

+-----------------------------------------------------------------------+
|                    ENCAPSULATION SÉCURISÉE RICEGUARD                  |
+-----------------------------------------------------------------------+
|  [ Paquet IP d'origine de l'utilisateur ]                             |
|         │                                                             |
|         ▼                                                             |
|  [ AUCUNE COMPRESSION ]      -> Suppression du canal auxiliaire LZ77   |
|         │                                                             |
|         ▼                                                             |
|  [ Remplissage normalisé ]   -> Arrondi des tailles selon un pas fixe  |
|         │                                                             |
|         ▼                                                             |
|  [ ChaCha20-Poly1305 AEAD ]  -> Chiffrement authentifié en temps fixe  |
|         │                                                             |
|         ▼                                                             |
|  [ Datagramme UDP externe ]  -> Profil de trafic régulier sur le câble |
+-----------------------------------------------------------------------+

RiceGuard applique des principes de protection éprouvés :

  • Rejet total de la compression préalable : Les modules de compression sont absents de la chaîne de transport. Les paquets IP sont chiffrés directement dans leur format d'origine.
  • Remplissage contrôlé (Padding) : RiceGuard exploite les champs de remplissage du format de trame pour aligner les petits paquets de contrôle et les requêtes courtes sur des multiples de taille prédéfinis, neutralisant la prise d'empreinte fine par la taille.
  • Débit à la vitesse du câble : Sans décompression gourmande en ressources, le tunnel maintient un débit stable sur les liaisons fibre à haut débit sans saturer les files d'attente du noyau.

Les utilisateurs peuvent consulter les installateurs sécurisés pour ordinateurs et téléphones sur la page de téléchargement VPN.

Audit et sécurisation des déploiements VPN existants

Pour les administrateurs exploitant des passerelles VPN auto-hébergées ou des configurations traditionnelles, un audit immédiat s'impose pour désactiver la compression.

Vérification des fichiers de configuration OpenVPN

Ouvrez vos fichiers de configuration serveur (server.conf) et client (client.ovpn), puis repérez les directives suivantes :

# DIRECTIVES VULNÉRABLES - À RETIRER OU DÉSACTIVER :
comp-lzo yes
comp-lzo adaptive
compress lzo
compress deflate

Pour neutraliser l'attaque VORACLE, adaptez votre configuration vers un mode sans compression :

# CONFIGURATION SÉCURISÉE RECOMMANDÉE :
# Pour OpenVPN version 2.4+ :
compress migrate
comp-lzo no

# Pour OpenVPN version 2.5 et ultérieure :
# Désactivation totale de la compression :
compress stub-v2

L'application de comp-lzo no assure que les données ne subissent aucune altération de volume dépendante de leur contenu avant d'entrer dans le module de chiffrement.

Recommandations pour les gestionnaires d'infrastructure

  1. Adopter des protocoles modernes : Migrez progressivement vos tunnels vers des architectures comme WireGuard ou RiceGuard, exemptes de moteurs de compression.
  2. Généraliser TLS 1.3 et HSTS : Veillez à ce que vos applications Web internes imposent des connexions chiffrées de bout en bout pour empêcher l'injection de requêtes en clair.
  3. Auditer les équipements intermédiaires : Contrôlez que vos boîtiers d'optimisation WAN ou contrôleurs SD-WAN n'activent pas de compression transparente à votre insu.

L'histoire de la cryptographie rappelle régulièrement que les gains marginaux de performance créent souvent des failles profondes. Tenter de grapiller quelques octets par la compression détruit la confidentialité même promise par le chiffrement. Bannir la compression des tunnels VPN restaure une étanchéité cryptographique authentique pour l'ensemble des flux réseau.