Résumé

  • RFC 9841 ajoute à Brotli des dictionnaires partagés, de grandes fenêtres et un format d'encadrement ; compresseur et décompresseur doivent employer exactement le même dictionnaire.
  • Modifier le dictionnaire peut modifier le contenu reconstruit. L'observation de la taille compressée peut aussi révéler des éléments du message par le dictionnaire, ou du dictionnaire par le message.
  • La preuve exploitable doit donc réunir charge compressée, empreinte cryptographique du dictionnaire, provenance, périmètre, fraîcheur, version du décodeur et décision explicite de compresser ou non des secrets.

Un objet compressé n'est pas toujours un objet autonome. Il peut conserver une empreinte correcte, traverser intact le réseau et devenir pourtant indéchiffrable — ou pire, produire un résultat différent — parce qu'un fichier externe a changé. Dans un système à dictionnaire partagé, ce fichier ne décrit pas seulement une optimisation : il fournit une partie de l'entrée effective du décodeur.

RFC 9841, publié en septembre 2025 comme RFC Informational, formalise le Shared Brotli Compressed Data Format. Le texte brut et la source XML font foi avec l'édition HTML. La spécification étend Brotli par des dictionnaires partagés, une grande fenêtre et un encadrement. Elle ne démontre ni adoption, ni gain, ni sécurité d'une installation réelle.

L'optimisation fournit une partie du contenu

Le dictionnaire peut alimenter l'historique LZ77, remplacer la liste de mots statique de Brotli, remplacer ses transformations ou combiner ces fonctions selon le contexte. Il faut donc les mêmes octets des deux côtés. Un nom tel que « dictionnaire-produits-v3 » n'est pas une identité suffisante s'il pointe vers un objet mutable.

Pour reproduire un résultat, le reçu doit relier l'empreinte de la charge à celle du dictionnaire, au profil, à l'encadrement et à la version du décodeur. Il doit encore préciser la source de fabrication, l'approbateur, le périmètre autorisé, l'activation, la fin de vie et la version de repli. Zstandard montre que cette question dépasse Brotli : dès que des données extérieures contribuent à la reconstruction, elles font partie de l'artefact exploitable.

RFC 9841 propose un identifiant de 256 bits fondé sur HighwayHash pour reconnaître un élément d'un ensemble connu et digne de confiance. Elle avertit qu'il n'apporte pas de sécurité contre les collisions en environnement hostile. Une étiquette d'identification et une preuve d'intégrité adversariale sont deux fonctions différentes. Pour cette dernière, une empreinte cryptographique comme SHA-256 doit accompagner le reçu de provenance.

La fuite fonctionne dans les deux sens

La compression peut transformer une différence de longueur en oracle. Un adversaire place des fragments choisis près d'une donnée privée, observe la taille et apprend si ses hypothèses trouvent des répétitions. RFC 7457 inscrit CRIME parmi les attaques connues contre TLS ; CVE-2012-4929 en conserve une référence publique. Une étude des canaux auxiliaires de compression décrit la famille de risques au-delà d'un seul protocole.

L'apport décisif de RFC 9841 est d'inclure le dictionnaire dans les sources d'information. Le dictionnaire peut renseigner sur le contenu compressé, tandis que le contenu compressé peut renseigner sur le dictionnaire lorsque l'attaquant contrôle une entrée et mesure la longueur. Un dictionnaire bâti à partir de pages authentifiées, de phrases clients ou de modèles internes n'est donc pas automatiquement public parce qu'il porte l'étiquette « performance ».

La meilleure défense reste de ne pas compresser de données privées dans un contexte observable par l'attaquant. Même origine, absence de partage inter-domaines, faible contrôle de l'entrée hostile, renouvellement lent et séparation des contextes sont des atténuations utiles. Elles ne valent pas preuve universelle. Avant de compter les octets gagnés, l'équipe doit inventorier toutes les sources : charge, dictionnaire, préfixe contrôlable et état de contexte.

HTTP révèle les attributs oubliés

La spécification compagne RFC 9842, dont la fiche officielle est distincte, définit la négociation HTTP et les codages dcb et dcz. Elle exige une empreinte SHA-256 dans Available-Dictionary, des contraintes de même origine et de lisibilité de la réponse, ainsi qu'un dictionnaire frais ou explicitement autorisé à rester périmé. Si ces conditions échouent, la réponse doit être abandonnée.

Ces obligations s'insèrent dans HTTP Semantics, HTTP Caching et les directives de réponse périmée. RFC 6265 fournit un point de comparaison pour l'état associé à un site. RFC 9842 avertit en outre qu'une empreinte de dictionnaire peut servir de jeton de suivi et demande un partitionnement au moins comparable à celui des cookies.

Le suivi et le partitionnement dans le navigateur méritent un futur article séparé. Pour la présente décision, la conséquence est plus étroite : l'identité du dictionnaire comprend origine, droit de lecture, fraîcheur et périmètre de stockage. Un chemin de fichier ne porte aucune de ces garanties.

L'IANA publie le registre des paramètres HTTP et content codings ainsi que celui des noms de champs HTTP. RFC 9651 rappelle la valeur de métadonnées structurées. Un enregistrement coordonne les noms ; il ne certifie pas les pratiques d'un CDN, d'un serveur ou d'un navigateur.

Tester l'échec avant le rendement

Une campagne crédible substitue un autre dictionnaire sous le même nom, force une version périmée, présente la bonne empreinte depuis une mauvaise origine, change le décodeur, place des fragments choisis près d'un secret, dépasse les limites de décompression et retire complètement la dépendance. Le système échoue-t-il fermé, revient-il silencieusement à un autre mode, ou sert-il un contenu différent ?

Chaque mesure de ratio doit conserver les identités exactes du message et du dictionnaire. On y ajoute mémoire maximale, latence, comportement de repli, déterminisme et variance de taille sous sondage. Un chiffre de compression sans ce contexte n'est pas comparable et ne peut pas soutenir une décision de production.

Cette discipline suit un principe de spécification minimale : le standard partagé fixe les identifiants et contraintes indispensables ; l'opérateur décide localement quels flux peuvent être compressés, selon quel rythme et avec quel risque. Le code en exécution apporte la preuve. Le mécanisme commun n'a pas à devenir une autorité générale, mais aucune autorité locale ne peut ignorer la dépendance qu'elle active.

Limites de la conclusion

Aucun navigateur, serveur, CDN, décodeur ou dictionnaire réel n'a été examiné ici. Aucun taux de compression, coût CPU, usage mémoire, taux de fuite ou succès d'attaque n'a été mesuré. La publication des RFC ne prouve pas le déploiement.

La conclusion solide tient dans la frontière : si des octets externes sont nécessaires pour reconstruire un message, ils appartiennent à son identité opérationnelle. S'ils peuvent interagir avec des secrets par la longueur compressée, ils appartiennent aussi au périmètre de confidentialité. L'économie d'octets doit arriver avec ce reçu complet.

Sources