Résumé

  • IMAP COMPRESS n'activait DEFLATE qu'après un OK étiqueté : le serveur commençait juste après le CRLF de cette réponse, tandis que le client compressait sa première commande ultérieure.
  • La mémoire qui raccourcissait commandes, en-têtes et texte liait aussi tous les octets suivants à un état caché. Les recommandations de sécurité postérieures ont montré que la longueur chiffrée pouvait rester informative, sans démontrer pour autant une attaque propre à IMAP.

Un CRLF sépara deux lectures du même flux

IMAP organisait déjà le dialogue autour de commandes étiquetées, de données non sollicitées et d'un résultat final portant la même étiquette. RFC 4978 ne créa aucune nouvelle famille de réponse. Le serveur annonçait COMPRESS=DEFLATE, le client demandait COMPRESS DEFLATE, puis OK, NO ou BAD rendait le verdict.

La simplicité visuelle masquait une règle sévère. Le client ne pouvait rien envoyer de plus avant de connaître la réponse. Si elle était positive, sa commande suivante devait être compressée. Le serveur, lui, envoyait encore le OK en clair et enclenchait son compresseur immédiatement après le CRLF final. Un refus conservait l'ancien mode dans les deux sens.

La position d'un octet devenait ainsi une frontière de droit. Un client trop pressé livrerait du texte à un décompresseur. Un serveur retardataire ferait passer des bits compressés pour de la syntaxe IMAP. TCP pourrait transmettre sans aucune perte et la session deviendrait tout de même incompréhensible : ce ne seraient pas les octets qui divergeraient, mais leur signification.

Une capacité ne promettait aucun gain

L'annonce attestait seulement que le serveur connaissait l'algorithme. Elle ne garantissait ni réduction pour cette boîte aux lettres, ni coût CPU acceptable, ni confidentialité. Chaque sens possédait son propre compresseur, libre de choisir son effort ; l'autre extrémité devait suivre le flux produit.

Les refus maintenaient ce périmètre. Si le même mécanisme était déjà actif dans une autre couche, le serveur pouvait répondre NO avec COMPRESSIONACTIVE. Une seconde activation de l'extension était invalide. Deux surfaces de négociation ne donnaient pas le droit d'empiler aveuglément deux états identiques.

Il n'existait pas non plus un dictionnaire unique et magique pour toute la connexion. Les commandes répétées formaient l'histoire montante. Les réponses, noms de champs et contenus formaient l'histoire descendante. Chaque émetteur se souvenait de ses propres octets.

L'ordre des couches n'était pas l'ordre des commandes

La session pouvait également acquérir une couche de sécurité SASL et TLS. Pour l'émission, la règle était fixe : compresser d'abord, appliquer ensuite la protection SASL éventuelle, puis TLS. À la réception, les opérations étaient inversées.

Cet empilement restait le même même si le client avait demandé les fonctions dans un autre ordre. La chronologie administrative et l'ordre de transformation des données n'étaient pas confondus. COMPRESS devait donc connaître l'état d'IMAP au lieu de se présenter comme un tuyau transparent.

Le cœur actuel d'IMAP4rev2 conserve ce principe général pour les transitions de sécurité : la réponse de succès désigne le point précis où une nouvelle couche commence. Une connexion peut changer de protection ou de représentation, mais jamais au prix de deux frontières concurrentes.

Le vocabulaire répétitif nourrissait la mémoire

IMAP offrait un terrain favorable. Le client réutilisait peu de verbes. Le serveur répétait les formes de réponse et les noms d'en-tête. Dans un fil de discussion, les citations reproduisaient de longues séquences. L'histoire DEFLATE permettait de remplacer ces répétitions par des références plus courtes.

Puis arrivait une pièce jointe. Une archive déjà comprimée ou une image JPEG gagnait peu, tout en chassant du dictionnaire les motifs utiles au protocole. Le compresseur pouvait consommer du temps à apprendre une matière qui ne reviendrait pas. Le RFC évoquait alors des vidages complets autour de grands littéraux et une baisse d'effort pour les formats apparemment incompressibles. Ces décisions restaient locales, invisibles dans la grammaire IMAP.

L'intérêt venait précisément de cette proximité avec l'application. Celle-ci savait si les prochains octets étaient une réponse, des en-têtes, du texte ou un littéral. Elle pouvait mieux économiser ; elle devenait aussi responsable de la mémoire ainsi constituée.

Le chiffrement ne faisait pas disparaître la longueur

En 2007, la section de sécurité de COMPRESS renvoyait en une phrase aux considérations de la compression TLS de l'époque. Les attaques étudiées ensuite modifièrent le jugement collectif. CRIME et des travaux voisins montrèrent qu'un contenu pouvait rester secret tout en laissant sa longueur observable. Quand une valeur secrète et une entrée influencée par l'attaquant alimentent la même histoire, des essais répétés peuvent révéler si une supposition ressemble au secret.

Les cas recensés par l'IETF concernent TLS et le Web. Ils ne prouvent ni incident IMAP COMPRESS ni vulnérabilité universelle. Ils suffisent toutefois à réfuter l'équation « compressé puis chiffré, donc sans information résiduelle ».

La pratique actuelle déconseille la compression ordinaire de TLS 1.2, sauf démonstration de sûreté très prudente ; TLS 1.3 l'a retirée. Elle avertit aussi que la compression au niveau applicatif peut créer une fuite que TLS ne saurait corriger. La connaissance du protocole améliore le rendement, mais elle impose de décider quelles origines de données ont le droit de partager une histoire.

Toute mémoire cachée exige un responsable

Les messages logiques d'IMAP ne changeaient pas, mais leurs octets dépendaient désormais des octets antérieurs. Le bénéfice supposait un accord continu sur l'activation, la direction, l'algorithme et l'état. Une erreur de décodage, une dépense excessive ou un soupçon de fuite ne se lisaient pas simplement dans une capture chiffrée.

La leçon n'est pas une interdiction sommaire. Il faut nommer le contexte, les acteurs capables d'en influencer l'entrée, ceux qui observent sa longueur, sa durée de vie, ses limites de ressources et la voie de désactivation. Une optimisation qui se souvient est déjà une machine à états.

Sources et limites

Le format DEFLATE est défini dans RFC 1951. La capacité IMAP, la frontière, l'ordre des couches et les conseils de réglage viennent de RFC 4978. La classe d'attaques est résumée par RFC 7457, le cœur actuel d'IMAP figure dans RFC 9051, les recommandations TLS actuelles dans RFC 9325, et la capacité demeure au registre IMAP de l'IANA. Ces sources ne mesurent pas l'usage présent et ne rapportent pas de compromission IMAP COMPRESS précise.