Résumé

  • Le compteur de cohérence sur douze bits de RFC 3078 permettait de constater qu’un paquet MPPE manquait ou arrivait hors séquence ; il ne reconstituait ni le chiffré perdu ni les données applicatives.
  • En mode sans état, le récepteur pouvait faire avancer la clé jusqu’au compteur observé. En mode avec état, il devait abandonner les paquets, envoyer un CCP Reset-Request et attendre que l’émetteur pose une nouvelle frontière FLUSHED.

Savoir que quelque chose manque ne rend pas le paquet lisible

Le cas le plus instructif commence après une perte. Le récepteur attend une valeur du compteur, mais en voit une autre. Cette différence est une information précise : le flux n’a pas suivi la séquence prévue. Elle ne dit pourtant pas quel contenu a disparu, pourquoi il a disparu, ni si l’état de chiffrement local correspond encore à celui de l’émetteur.

En mode MPPE avec état, cette dernière incertitude imposait une réaction stricte. Le récepteur devait rejeter le paquet qui avait révélé la perte, émettre un Reset-Request CCP vide, puis éliminer silencieusement les paquets suivants jusqu’à l’arrivée d’un paquet portant FLUSHED. Après la requête, l’émetteur réinitialisait ses tables RC4 et marquait son prochain paquet. Ce paquet, et non un Reset-Ack séparé, matérialisait la reprise.

Le compteur avait donc rempli sa fonction sans réparer le dommage. Il avait produit une preuve de discontinuité. La remise en cohérence constituait un autre événement, et la livraison applicative encore un autre.

La protection dépendait d’une négociation antérieure

Publié en mars 2001 comme RFC informationnelle, RFC 3078 décrivait MPPE pour les paquets PPP et mettait à jour l’usage de l’option partagée avec MPPC, définie par RFC 2118. Le texte n’établissait pas une norme Internet.

MPPE se négociait dans l’option 18 du Compression Control Protocol. L’initiateur proposait les capacités acceptées ; le répondant devait normalement n’en retenir qu’une parmi 128, 56 ou 40 bits, en plus de la possibilité de demander le mode sans état. Si personne ne tentait la négociation, le comportement par défaut restait l’absence de chiffrement. Si la négociation était tentée puis échouait, le lien devait en principe être arrêté.

Avant d’envoyer des données MPPE, PPP devait atteindre la phase des protocoles réseau et CCP l’état Opened. Voilà une chaîne que les journaux peuvent facilement écraser sous une seule étiquette « chiffré ». Une authentification réussie n’était pas l’ouverture de CCP. La présence d’une clé n’était pas le choix d’un mode. Une offre à 128 bits n’était pas la preuve que cette option avait été acceptée.

Les documents voisins montrent cette séparation. RFC 2548 transportait des clés MPPE distinctes selon le sens dans RADIUS. RFC 3079 décrivait des dérivations à partir de secrets d’authentification. RFC 1962 fournissait la machine de négociation et de réinitialisation CCP ; RFC 1661, les phases de PPP. RFC 3078 commençait lorsque les paquets chiffrés et leur état devaient réellement circuler.

Douze bits conservaient une position, pas une histoire

Le compteur de cohérence augmentait à chaque paquet et revenait à zéro après 4095. Le récepteur comparait cette valeur avec celle qu’il avait gardée pour détecter une séquence rompue et calculer, selon le mode, les changements de clé nécessaires.

Ce nombre ne contenait aucune copie du paquet absent. Il n’authentifiait pas non plus sa propre cause. Une file saturée, un filtre, un réordonnancement, une perte physique ou une modification hostile pouvaient tous conduire à une observation anormale. Même une suite sans trou n’attestait pas que le texte clair avait atteint l’application.

RFC 3078 précisait que MPPE n’exigeait pas un lien fiable et que le mécanisme de transmission fiable de RFC 1663 ajoutait souvent un coût inutile pour la synchronisation. Cette autonomie concernait l’évolution des tables de chiffrement, non la récupération du contenu. Les protocoles supérieurs continuaient à supporter la perte.

Le bit indiquant un contenu chiffré n’était pas davantage une preuve cryptographique. Seule une plage déterminée de protocoles PPP passait dans MPPE. Le reste du trafic PPP gardait son numéro d’origine. Une mesure sérieuse devait donc identifier ce qui était censé être protégé, pas seulement observer une trame portant l’étiquette MPPE.

Le mode sans état avançait jusqu’au nouvel indice

En mode sans état, la clé de session changeait avec chaque compteur. L’émetteur la faisait évoluer avant le chiffrement ; le récepteur, après lecture du compteur mais avant le déchiffrement. Chaque paquet chiffré portait FLUSHED.

Si la dernière valeur reçue était deux et la suivante cinq, le récepteur exécutait trois évolutions de clé. Il pouvait alors tenter de déchiffrer le paquet cinq sans demander une réinitialisation au pair. La perte était franchie dans l’état cryptographique, mais les paquets trois et quatre ne revenaient pas.

Le terme « sans état » ne signifiait donc pas « sans mémoire ni accord ». Les deux extrémités partageaient une clé initiale, une fonction d’évolution, le sens du compteur et le mode choisi. La différence était que chaque paquet apportait assez d’indications pour reconstruire localement l’état courant.

Le mode avec état transformait le retour en dépendance

En mode avec état, la clé changeait lorsque l’octet faible du compteur valait 0xFF. Si ce paquet-charnière disparaissait, l’émetteur passait à la clé suivante tandis que le récepteur restait sur l’ancienne. Le paquet ultérieur pouvait annoncer l’écart sans être déchiffrable en sécurité.

Reset-Request rendait alors le chemin retour indispensable à la poursuite du trafic aller. Une capture limitée à un seul sens pouvait voir le trou et, plus tard, un paquet FLUSHED ; elle ne prouvait ni l’émission de la demande par ce récepteur ni la causalité entre demande et réponse. Inversement, enregistrer la demande sans le premier texte clair correctement récupéré ne prouvait pas le rétablissement.

Le RFC avertissait en outre que la réinitialisation avec état pouvait conduire deux paquets à employer la même clé. Il déconseillait donc ce mode sur des environnements à pertes, par exemple des tunnels de couche 2 sur Internet. L’avertissement portait sur cette combinaison précise. Il ne mesurait pas la fréquence des déploiements ni un incident concret.

Le choix lui-même n’était pas protégé en intégrité

La négociation MPPE ne bénéficiait pas d’une protection d’intégrité. Un attaquant actif pouvait modifier les bits des options supportées et influencer la force choisie. Une configuration locale refusant les variantes indésirables réduisait le risque, sans transformer l’échange en preuve authentifiée.

Le texte signalait aussi la modification possible du compteur, qui provoquerait une désynchronisation, et l’inversion du bit de données chiffrées, utilisable pour un déni de service. La confiance ne pouvait donc pas reposer sur la seule apparence d’un en-tête. Il fallait joindre l’observation réseau, la configuration acceptée par chaque pair et le résultat du déchiffrement.

La mention de RC4 impose enfin une prudence historique. RFC 4345 proposa plus tard des modes Arcfour améliorés pour SSH, un autre protocole. Il rappelle qu’une longueur de clé n’est pas une évaluation complète, mais ne prouve ni migration de MPPE ni propriété rétroactive.

Conserver les transitions plutôt qu’un verdict

Le reçu utile relie l’identité des pairs, la session PPP, le résultat d’authentification, l’origine de la clé sans exposer le secret, les échanges CCP, la force et le mode retenus, puis l’entrée dans Opened. Pour chaque sens, il conserve le compteur attendu et reçu, les passages à zéro, les trous, les paquets-charnières, FLUSHED, les rejets, les Reset-Request, l’attente et le premier déchiffrement valide après reprise.

Il doit ensuite remonter à l’application. Un état RC4 resynchronisé ne démontre pas que le message manquant a été rejoué, que le protocole supérieur a réparé sa séquence ou que l’utilisateur a obtenu le résultat attendu.

La discipline des couches de réalité de Lu Heng rend cette limite explicite : authentifier, dériver, transporter une clé, négocier, recevoir, détecter, resynchroniser, déchiffrer et livrer sont des verbes différents. Le code en fonctionnement peut les relier ; aucun bit ne les fusionne.

Sources