Pourquoi le chiffrement seul n’arrête pas un paquet rejoué

Les paquets protégés n’expirent pas cryptographiquement, donc un paquet valide il y a cinq minutes est encore valide maintenant, parce que le chiffrement et la protection de l’intégrité ne disent rien sur le moment où les octets ont été produits. Un attaquant qui peut capturer et renvoyer du trafic n’a pas besoin de casser le chiffrement. C’est pourquoi tout protocole de tunnel sérieux transporte un état de séquence à côté de ses clés.

Le mécanisme est petit, et ses modes de défaillance se confondent facilement avec une perte de paquets.

Un texte chiffré valide n’est pas un texte chiffré frais

L’authentification répond à une question : ces octets viennent-ils, non modifiés, d’un détenteur de la clé. Elle ne répond pas à la question de savoir si c’est la première fois que le récepteur les voit. Un paquet rejoué réussit parfaitement le premier test, et c’est exactement pourquoi la seule vérification d’intégrité ne peut pas arrêter un rejeu et pourquoi le protocole a besoin d’une seconde règle sur l’acceptation. Un récepteur qui ne fait qu’authentifier n’a aucune défense contre un attaquant qui détient un enregistrement.

Cette règle est bon marché à implémenter et bon marché à énoncer : accepter un paquet protégé donné une fois, sous une clé donnée. Tout le reste dans ce domaine découle de la façon dont l’implémentation suit cette unique fois.

Lire un rejet de rejeu comme un échec de déchiffrement vous envoie dans le sous-système complètement erroné.

Un numéro de séquence et une fenêtre

IPsec ESP porte un numéro de séquence et le récepteur tient une fenêtre glissante des valeurs récemment acceptées, la spécification ESP décrivant la taille de fenêtre par défaut et l’option de l’étendre. WireGuard suit une autre voie avec un compteur par clé et une vérification explicite contre lui. Aucune des deux conceptions ne suppose que les paquets arrivent dans l’ordre, car les réseaux réels les réordonnent. Les deux tolèrent le réordonnancement, et aucune ne tolère la répétition.

C’est la fenêtre qui rend cette tolérance possible. Un paquet légèrement en retard sur la valeur la plus élevée observée peut encore être accepté s’il ne l’a pas déjà été ; un paquet très en retard, ou dont l’emplacement est déjà marqué, est rejeté. Augmentez la fenêtre et vous tolérerez plus de réordonnancement au prix de plus d’état par association.

Les compteurs de diagnostic vous montrent dans quel cas vous êtes. Les rejets de rejeu incrémentent un compteur spécifique plutôt qu’une erreur générique, et lire ce compteur est la première observation utile.

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

L’état appartient à la clé, pas à l’hôte

L’état du compteur est lié à une association de sécurité ou à une époque de clé, donc un renouvellement de clé crée un contexte neuf et son propre espace de séquence. Effacer un compteur sans remplacer la clé, ou réutiliser une association après une réinitialisation manuelle, brise l’hypothèse dont dépend la fenêtre du récepteur. C’est pourquoi il existe un renouvellement de clé piloté par le protocole plutôt qu’un bouton de réinitialisation visible par l’opérateur.

Quand un tunnel se comporte mal après une intervention manuelle, demandez si l’intervention a touché l’état de séquence. Une configuration qui semble identique peut se comporter différemment parce que l’état hérité n’est pas celui qu’elle attend.

Diagnostiquez la cause avant de désactiver quoi que ce soit

La perte, le réordonnancement, le trafic dupliqué et un défaut d’implémentation se manifestent tous comme des retransmissions, et un seul d’entre eux est un problème de rejeu. Désactiver la vérification pour faire taire le bruit supprime la propriété sur laquelle vous comptiez et rend la cause d’origine plus difficile à trouver, car désormais les retransmissions n’ont plus aucune explication.

Capturez des preuves limitées : identifiants d’association, numéros de séquence et compteurs, sans les charges utiles. Cela suffit à distinguer un doublon d’une arrivée réordonnée, et cela ne transforme pas votre fichier de diagnostic en copie du trafic de l’utilisateur.

Ce que la vérification ne promet pas

La protection contre le rejeu est une propriété du traitement des paquets à l’intérieur d’un protocole. Elle ne signifie pas que l’opérateur ne tient aucun journal, qu’un site web ne peut pas reconnaître un compte ou qu’une session est anonyme. Ce sont des questions distinctes sur des systèmes distincts, et une conception anti-rejeu solide n’en résout aucune.

Un logiciel maintenu avec des réglages pris en charge est le contrôle pratique dont dispose un utilisateur. Le protocole traite le paquet ; tout le reste demeure une décision d’exploitation.