1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Titre: RFC 8054: Network News Transfer Protocol (NNTP) Extension for Compression
Auteur:
Date: Thu 26 Jan 2017 01:00:00 +0100
Lien: https://www.bortzmeyer.org/8054.html
Ce nouveau RFC définit un mécanisme standard de compression des news échangées
en NNTP, sur Usenet.
NNTP, normalisé dans le RFC 3977 est un protocole gourmand en débit. Comprimer
les données transmises est donc très souhaitable. C'est aussi un protocole très
ancien, ce qui se voit dans certaines références du RFC, comme l'allusion à la
compression PPP du RFC 1962 ou bien à la compression par modem comme V42bis :-)
Mais, malgré ce besoin de compression, il n'y avait pas encore de solution
standard en NNTP. Un certain nombre de mécanismes non-standards avaient été
déployés avec des noms comme XZVER, XZHDR, XFEATURE COMPRESS, ou MODE COMPRESS.
Outre l'absence de normalisation, ils souffraient de ne comprimer que les
réponses du serveur de news.
Compte-tenu du déploiement de plus en plus fréquent de TLS, pour assurer la
confidentialité des échanges, il avait été envisagé à une époque de compter sur
le mécanisme de compression de TLS (RFC 4642). Celui-ci présente
malheureusement des dangers, qui fait que son usage est déconseillé dans
beaucoup de cas (section 3.3 du RFC 7525, et section 2.6 du RFC 7457). En
outre, la solution de ce RFC bénéficie de davantage de souplesse : elle peut
par exemple n'être activée qu'une fois l'authentification faite, pour éviter
les attaques comme CRIME (voir aussi les sections 2.2.2 et 7 de notre RFC, pour
tous les détails de sécurité).
Pour assurer l'interopérabilité maximale, un seul algorithme de compression est
défini, et il est, logiquement, obligatoire. Cela garantit qu'un client et un
serveur NNTP auront toujours cet algorithme en commun. Il s'agit de Deflate,
normalisé dans le RFC 1951.
(Un petit point qui n'a rien à voir avec NNTP et la compression : comme le
demandait l'Internet-Draft qui a donné naissance à notre RFC, j'ai mis un
accent à la première lettre du nom d'un des auteurs, ce qui n'est pas possible
dans le RFC original, cela ne le sera que lorsque le RFC 7997 sera mis en
œuvre.)
Maintenant, les détails techniques (section 2 du RFC). Le serveur doit annoncer
sa capacité à comprimer en réponse à la commande CAPABILITIES. Par exemple (C =
client, S = serveur) :
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] COMPRESS DEFLATE SHRINK
[S] LIST ACTIVE NEWSGROUPS
[S] .
L'annonce de la capacité est suivie de la liste des algorithmes gérés. On
trouve évidemment l'algorithme obligatoire DEFLATE mais aussi un algorithme
non-standard (imaginaire, ce n'est qu'un exemple) SHRINK.
Le client peut alors utiliser la commande COMPRESS, suivie du nom d'un
algorithme (cette commande a été ajoutée au registre IANA des commandes NNTP[1]
). Voici un exemple où le serveur accepte la compression :
[C] COMPRESS DEFLATE
[S] 206 Compression active
(À partir de là, le trafic est comprimé)
Attention à ne pas confondre la réponse du serveur à une demande de ses
capacités, et la commande envoyée par le client (dans les deux cas, ce sera une
ligne COMPRESS DEFLATE).
Et voici un exemple où le serveur refuse, par exemple parce que la compression
a déjà été activée :
[C] COMPRESS DEFLATE
[S] 502 Command unavailable
Si on utilise TLS, ce qui est évidemment recommandé pour des raisons de
confidentialité et d'authentification, l'envoyeur doit d'abord comprimer, puis
(si SASL est activé) appliquer SASL (RFC 4422), puis seulement à la fin
chiffrer avec TLS. À la réception, c'est bien sûr le contraire, on déchiffre le
TLS, on analyse SASL, puis on décomprime.
Voici un exemple d'un dialogue plus détaillé, avec TLS et compression :
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] STARTTLS
[S] AUTHINFO
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
(Négociation TLS)
(Désormais, tout est chiffré)
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO USER michu
[S] 381 Enter passphrase
[C] AUTHINFO PASS monsieur
[S] 281 Authentication accepted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
(Désormais, toutes les données envoyées sont comprimées, puis chiffrées)
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] LIST ACTIVE NEWSGROUPS
[S] .
Et voici deux exemples où le serveur refuse la compression. D'abord parce qu'il
ne peut pas (manque de mémoire, par exemple) :
[C] COMPRESS DEFLATE
[S] 403 Unable to activate compression
Et ici parce que le client essaie d'utiliser un algorithme que le serveur ne
connait pas :
[C] COMPRESS SHRINK
[S] 503 Compression algorithm not supported
La liste des algorithmes standards (pour l'instant réduite à un seul) est dans
un registre IANA[2].
NNTP est un protocole dont les spécificités posent des problèmes amusants
lorsqu'on veut comprimer son trafic (section 3 du RFC). Les messages sont très
divers, ce qui peut être contrariant pour une compression fondée sur un
dictionnaire. Les réponses à certaines commandes (DATE, GROUP, NEXT, et le
CHECK du RFC 4644) sont peu comprimables. Par contre, les réponses à LIST,
LISTGROUP ou NEWNEWS sont facilement réduites à 25 à 40 % de la taille
originale avec zlib.
En outre, les news envoyées sont dans des formats différents. Un article sera
parfois du texte seul, relativement court (et souvent uniquement en ASCII) et
se comprimera bien. Les textes plus longs sont souvent envoyés sous un format
déjà comprimé et, là, le compresseur NNTP va s'essouffler pour rien. Mais il y
a aussi souvent des données binaires (images, par exemple), encodées en Base64
ou uuencode. On peut souvent les réduire à 75 % de l'original. (Deflate marche
bien sur des données en 8 bits mais l'encodage lui dissimule la nature
8-bitesque de ces données.) Si les données sont encodées en yEnc, elles seront
moins compressibles.
Il y a apparemment au moins un logiciel serveur (INN) et un client (flnews[3])
qui gèrent cette compression.
Merci à Julien Élie pour sa relecture attentive (et pour avoir trouvé au moins
une grosse faute.)
Liens:
[1]: https://www.iana.org/assignments/nntp-parameters/nntp-parameters.xml#nntp-parameters-1 (lien)
[2]: https://www.iana.org/assignments/nntp-compression-algorithms/nntp-compression-algorithms.xml (lien)
[3]: http://micha.freeshell.org/flnews/ (lien)
|
