De nombreux internautes pensent qu'ouvrir un onglet en navigation privée élimine toute forme de surveillance en ligne. Dans le modèle de sécurité conventionnel, fermer une fenêtre privée purge les cookies de session, les données localStorage et les bases IndexedDB. Toutefois, les régies publicitaires et les courtiers en données exploitent des mécanismes plus profonds nichés au cœur des protocoles Internet. En détournant les fonctions de mise en cache élémentaires, ils génèrent des identifiants intersessions persistants appelés supercookies.

Deux vecteurs majeurs de pistage avec état opèrent directement au niveau des protocoles réseau : les vecteurs d'état HTTP Strict Transport Security (HSTS) et les arbres de redirection du cache des favicons. Ces méthodes exploitent les fonctionnalités de performance et de sécurité des navigateurs pour inscrire un identifiant numérique directement sur l'appareil sans solliciter les cookies traditionnels.

[Navigateur Client]
  │
  ├─ Cookies Conventionnels   ──> [Purgés à la fermeture privée]
  ├─ LocalStorage / IndexedDB ──> [Purgés à la fermeture privée]
  │
  ├─ Table d'état HSTS        ──> [Persiste dans le profil réseau]
  └─ Base SQLite des Favicons ──> [Partagée entre fenêtres et onglets]

Fonctionnement des supercookies HSTS

Le standard HTTP Strict Transport Security (HSTS), défini par l'IETF dans le RFC 6797, ordonne au navigateur de communiquer avec un domaine exclusivement via des connexions chiffrées HTTPS. Lorsqu'un serveur web transmet l'en-tête de réponse Strict-Transport-Security: max-age=31536000; includeSubDomains, le client enregistre une règle de sécurité locale. Durant les 365 jours suivants, toute tentative de joindre ce domaine en HTTP clair est automatiquement basculée en HTTPS avant même que le paquet ne quitte la carte réseau.

Conçue pour parer aux attaques par rétrogradation de protocole, cette fonctionnalité crée involontairement un bit d'état persistant : un sous-domaine spécifique est soit inscrit dans la table HSTS locale (valeur 1), soit absent (valeur 0).

Réseau de serveurs de suivi (tracker-network.example)
  ├── bit00.tracker-network.example (HSTS configuré   = 1)
  ├── bit01.tracker-network.example (HSTS non présent = 0)
  ├── bit02.tracker-network.example (HSTS configuré   = 1)
  └── ... (de 32 à 64 sous-domaines distincts)

Les plateformes de pistage assemblent ces indicateurs binaires pour former un identifiant complet :

  1. Phase d'écriture de l'état : Lorsqu'un internaute visite un site hébergeant un script d'analyse, celui-ci déclenche des requêtes invisibles vers 32 sous-domaines distincts (bit01 à bit32). Pour chaque bit de l'identifiant calculé (par exemple 11010010...), le serveur ne renvoie d'en-tête HSTS en HTTPS que pour les sous-domaines correspondant à 1. Les sous-domaines associés à 0 ne reçoivent aucun en-tête de sécurité.
  2. Phase de lecture de l'état : Lors d'une visite ultérieure ou sur un autre site partenaire, le script génère des requêtes d'images HTTP standards (http://bitXX...) vers l'ensemble des 32 sous-domaines. Si un sous-domaine possède déjà une directive HSTS, le navigateur transforme la requête en https:// en interne. Dans le cas contraire, le paquet part en http:// non chiffré.
  3. Reconstitution de l'identifiant : Le serveur distant analyse sur quel port arrivent les requêtes : le port 443 (HTTPS) ou le port 80 (HTTP). En attribuant la valeur 1 au port 443 et la valeur 0 au port 80, le collecteur reconstitue la clé 32 bits de l'appareil en quelques fractions de seconde.

Dans la mesure où les boîtes de dialogue de nettoyage séparent habituellement les cookies des paramètres de sécurité des protocoles, les règles HSTS subsistent souvent après une purge ordinaire.

Empreinte via le cache des favicons

La mise en cache des favicons offre une surface de suivi encore plus discrète. Les navigateurs actuels stockent les icônes de sites dans une base SQLite dédiée sur disque (telle que la table Favicons de Chromium) pour afficher instantanément les onglets, favoris et historiques sans bloquer l'affichage par des requêtes réseau.

Contrairement au cache HTTP classique qui respecte les directives Cache-Control, le chargement des favicons a longtemps été traité en dehors du bac à sable du document :

[Moteur de rendu du navigateur]
  │
  ├─ Étape 1 : Requête du document HTML principal
  │
  ├─ Étape 2 : Détection de la balise <link rel="icon" href="/node-A.ico">
  │
  ├─ Étape 3 : Consultation de la base SQLite locale des favicons
  │     ├── Présent en cache : lecture disque directe (aucun paquet réseau)
  │     └── Absent du cache : émission d'un HTTP GET vers le serveur
  │
  └─ Analyse distante : enregistrement des requêtes reçues pour déterminer le code

Des travaux présentés lors du symposium USENIX Security ont révélé qu'un serveur peut construire un arbre de redirection dynamique en HTTP 302 à travers une séquence de favicons. Si le navigateur a déjà mémorisé une branche spécifique de l'arbre, il utilise l'icône locale et interrompt l'échange réseau. Si l'icône manque, une requête réseau est transmise. En cartographiant les requêtes reçues, le serveur localise l'appareil dans l'arbre binaire et lui assigne une empreinte matérielle constante.

Limites des défenses intégrées aux navigateurs

Les éditeurs de navigateurs ont déployé des contre-mesures techniques notables :

  • Cloisonnement de l'état (State Partitioning) : Les moteurs récents appliquent un double partitionnement des caches (comme Total Cookie Protection sur Firefox et Network State Partitioning sur Chromium). La clé de cache associe le domaine de premier niveau au domaine de la ressource (top_level_site, resource_site). Un bit positionné sur un site A ne peut ainsi être lu directement depuis un site B.
  • Tables HSTS temporaires en navigation privée : Les versions récentes des navigateurs créent un espace HSTS éphémère pour les sessions privées, détruit à la fermeture de la fenêtre.

Néanmoins, l'isolation locale ne neutralise pas la corrélation au niveau du réseau :

  1. Masquage CNAME propriétaire : Lorsqu'un éditeur délègue un sous-domaine à un prestataire d'analyse via un enregistrement DNS CNAME, le script opère dans la partition du premier domaine, neutralisant le cloisonnement intersite.
  2. Composants WebView partagés sur mobile : Sous Android et iOS, de nombreuses applications intègrent des composants WebView système qui partagent la pile réseau et le cache sans appliquer les isolements stricts de la navigation privée de bureau.
  3. Corrélation par métadonnées réseau : Même si le cache est cloisonné, les serveurs d'analyse relient les différentes partitions entre elles grâce à l'adresse IP publique, au numéro de système autonome (ASN) du fournisseur d'accès et à l'empreinte TLS du client.

Neutralisation du profilage avec RiceGuard

Les protections du navigateur isolent les données locales sur le disque, mais restent inefficaces face aux marqueurs réseau utilisés pour relier les profils. Lorsqu'une infrastructure d'analyse reçoit des requêtes provenant de partitions distinctes, elle corrèle les données via l'adresse IP publique et la route réseau de l'utilisateur.

VPNRice neutralise ce pistage au niveau de la couche 3 grâce à l'architecture RiceGuard :

[Navigateur et applications du terminal]
  │
  │ (Sondes HSTS / Résolutions de sous-domaines / Requêtes favicons)
  ▼
[Interface réseau virtuelle RiceGuard]
  │
  ├─ Tunnel chiffré Chacha20-Poly1305 (RFC 8439)
  ├─ Relais DNS chiffré anti-fuites (interception ports 53 / 853)
  │
  ▼
[Cluster de serveurs de sortie VPNRice]
  │
  ├─ Adresse IP publique partagée au sein d'un large pool
  ├─ Décorrélation des attributs de routage ASN de l'opérateur
  │
  ▼
[Serveurs web de destination et réseaux d'analyse]
  1. Rupture des ancres d'identification réseau : RiceGuard achemine la totalité du trafic dans des tunnels WireGuard robustes. Lorsque les serveurs de suivi enregistrent des sondes HSTS ou des retours de favicons, l'adresse visible correspond aux passerelles partagées de VPNRice. Le réseau d'analyse ne peut rattacher le cache à une ligne résidentielle ou à un abonnement physique.
  2. Isolation complète des requêtes DNS : L'analyse des supercookies HSTS impose l'émission de nombreuses requêtes de sous-domaines (bit01 à bit32). RiceGuard achemine toutes les résolutions vers des serveurs DNS internes stricts et sans conservation de journaux, empêchant les intermédiaires locaux d'observer ces salves de requêtes caractéristiques.
  3. Rotation continue des points de sortie : En répartissant les connexions sortantes sur de multiples nœuds géographiques, le système empêche la constitution de profils télémétriques durables, rendant inexploitable la corrélation des partitions de cache.

Recommandations de configuration pour sécuriser l'appareil

Pour renforcer la protection contre le pistage par cache de protocole :

  • Purger régulièrement les entrées HSTS : Dans les navigateurs basés sur Chromium, ouvrez la page interne chrome://net-internals/#hsts, saisissez le nom de domaine concerné dans le champ « Delete domain security policies » et validez.
  • Vérifier le partitionnement sous Firefox : Dans about:config, assurez-vous que privacy.partition.network_state est bien configuré sur true pour garantir l'étanchéité des connexions et des caches par domaine source.
  • Activer une protection VPN continue de couche 3 : Maintenez la connexion VPNRice active sur vos ordinateurs et terminaux mobiles. Le chiffrement global du trafic réseau garantit que les particularités de protocole et les caches résiduels ne trahissent ni votre localisation réelle ni votre identité matérielle.