Résumé

  • La compression bidirectionnelle commençait juste après le CRLF de la réponse 206 et ne pouvait cesser qu’avec la connexion.
  • Une fois cette couche active, STARTTLS, AUTHINFO et MODE READER devenaient indisponibles ; réunir TLS, identité et compression exigeait précisément cet ordre.
  • Comme les données étaient comprimées avant SASL et TLS, la portée du dictionnaire, les longueurs visibles, le flush et la corruption relevaient de la sécurité autant que des performances.

Une économie qui fermait le chemin du mot de passe

Le client voit COMPRESS DEFLATE dans la liste des capacités et choisit immédiatement l’économie de bande passante. Le serveur accepte. Ce n’est qu’ensuite que le client veut sécuriser la liaison et s’authentifier. Il est trop tard pour cette connexion.

Le serveur répond 502 aux transitions pourtant valides dans l’état antérieur. Il ne punit pas une mauvaise syntaxe ; il protège la cohérence d’une couche déjà engagée et empêche les identifiants de traverser un historique de compression observable.

RFC 8054 fournit la séquence compatible avec les trois objectifs : STARTTLS, puis AUTHINFO, enfin COMPRESS. Le client qui inverse l’ordre doit quitter et recommencer sur une nouvelle connexion.

Le dernier CRLF non comprimé

La réponse 206 Compression active reste lisible en NNTP ordinaire. La couche s’applique immédiatement après le CRLF qui la termine, dans les deux sens. L’octet suivant doit donc être produit et interprété avec le nouvel état.

Cette frontière explique l’interdiction du pipeline. Le client ne peut envoyer la commande suivante avant de connaître le résultat. Après un refus, il continue en clair au niveau NNTP ; après le succès, les mêmes caractères doivent passer dans le flux comprimé.

Une erreur de syntaxe, un algorithme inconnu ou un manque de ressources déclenchent des réponses distinctes et laissent l’état intact. 206 est le seul passage. Sa précision protège non seulement le décodage, mais la capacité des deux extrémités à reconnaître encore les commandes.

Une couche générale plutôt qu’une collection d’exceptions

Des commandes non normalisées avaient comprimé certaines réponses du serveur. Elles ne réduisaient pas le trafic client et obligeaient chaque fonction NNTP à connaître sa variante. RFC 8054 plaça au contraire une transformation sans perte sous toutes les commandes et réponses suivantes.

Les commandes répétitives, les grandes listes, les en-têtes et les corps textuels pouvaient partager le mécanisme. Le document rapporte, à titre informatif, de fortes réductions pour certains blocs multilignes, mais beaucoup moins pour de petites réponses ou des pièces jointes déjà encodées. Ces observations ne sont ni une promesse universelle ni une mesure du déploiement actuel.

Le format DEFLATE de RFC 1951 est l’unique algorithme normalisé par l’extension et doit être implémenté. Chaque émetteur choisit ses paramètres raisonnables dans son sens ; le décompresseur opposé s’adapte. Une couche bidirectionnelle n’impose pas une politique de compression symétrique.

L’état courant retirait les capacités anciennes

Quand une couche de compression existait déjà, le serveur cessait d’annoncer COMPRESS et STARTTLS. Une seconde compression ou une négociation TLS ultérieure recevait 502. MODE READER ne pouvait plus suivre non plus.

La disparition de ces entrées décrivait la réalité de la connexion. RFC 3977 prévoit qu’une liste de capacités change au cours d’une session. Puisque la compression peut affaiblir le secret fourni par le chiffrement, RFC 8054 interdit aussi de se fier au résultat mémorisé d’une autre session.

Il n’existait pas de commande pour enlever la couche. QUIT et une nouvelle connexion étaient la procédure de retour. Un nouveau départ recréait un état commun certain ; une bascule locale risquait de faire lire des octets comprimés comme des lignes ordinaires.

Le compresseur voyait ce que le chiffrement allait cacher

À l’émission, les données passaient d’abord par COMPRESS, ensuite par une éventuelle couche de sécurité SASL, enfin par TLS. La réception inversait l’ordre. Le compresseur avait ainsi accès aux répétitions du texte avant que le chiffrement ne masque son contenu.

Le chiffrement ne masque pas nécessairement la longueur du résultat. Si un adversaire influence une partie du texte et observe les longueurs, la meilleure compression d’une hypothèse peut révéler une ressemblance avec un secret. RFC 8054 cite CRIME et BREACH comme exemples de cette famille d’attaques.

Les identifiants d’authentification constituaient le secret évitable le plus évident. Après COMPRESS, un client non authentifié ne devait plus tenter AUTHINFO. Le serveur supprimait la capacité ou n’en montrait aucun argument utilisable, puis refusait la commande.

Trois fonctions, trois autorités

RFC 4642 définit le passage de NNTP sous TLS. RFC 4643 définit l’authentification du compte. La compression n’accomplit aucune de ces fonctions : elle modifie la représentation des octets.

L’ordre obligatoire ne fusionne donc pas leurs preuves. TLS protège une liaison sans créer automatiquement un droit d’accès. AUTHINFO fait accepter une identité sans réduire le trafic. COMPRESS réduit certaines redondances sans chiffrer ni autoriser.

Faire TLS puis l’authentification permet de transmettre les secrets avant que le dictionnaire applicatif n’existe. Ajouter la compression ensuite devient une décision explicite sur les données déjà autorisées dans cette session.

Le dictionnaire avait lui aussi une frontière de confiance

Le dictionnaire rapproche des fragments provenant de moments différents. Sous une couche chiffrée, mélanger des articles publics connus et des articles confidentiels peut transformer cette mémoire en oracle de longueur. RFC 8054 recommande de ne pas les comprimer ensemble.

Deux articles confidentiels distincts devraient également éviter le même dictionnaire quand c’est possible. Effacer l’historique DEFLATE entre eux est l’une des mesures proposées. Cette opération ne change pas l’identité ou le chiffrement ; elle limite les données passées capables d’influencer la taille future.

La norme ne déclare pas toute compression chiffrée interdite. Elle demande de ne pas l’activer automatiquement sous une couche de sécurité sans choix informé de l’utilisateur. La décision dépend du contenu, de l’influence adverse et de l’isolation du dictionnaire.

Une histoire corrompue arrêtait la connexion

Tout octet soumis au compresseur devait apparaître dans la sortie et être suffisamment flushé pour que le destinataire le reconstitue. L’émetteur pouvait adapter son niveau autour d’un contenu peu compressible, mais ne pouvait retenir indéfiniment une interaction.

Si les données comprimées étaient invalides ou corrompues, le récepteur fermait immédiatement la connexion. Il ne cherchait pas une prochaine ligne plausible. Après divergence des dictionnaires, une apparence syntaxique ne prouvait plus que les deux parties partageaient la même histoire.

La fermeture était donc une restauration d’autorité. Elle abandonnait un état non démontrable et permettait à une nouvelle connexion de recommencer sur une frontière connue.

L’ordre était la propriété durable

Le registre IANA des paramètres NNTP inscrit la capacité COMPRESS et l’algorithme DEFLATE. Il garantit des noms et références communs, pas la présence, la performance ou la sécurité d’un serveur particulier.

La couche générale réduisait la répétition sans multiplier les commandes. En échange, son activation engageait la connexion, retirait des transitions futures et rendait la gestion des secrets dépendante de la séquence.

L’héritage n’est donc pas un taux de compression. C’est une règle d’assemblage : protéger la liaison, établir l’identité, puis seulement décider si la mémoire de compression peut voir le reste. La couche de performance venait en dernier parce qu’elle ne pouvait plus laisser passer sans risque certaines décisions qui auraient dû la précéder.

Sources