Résumé

  • Le correctif FORT 1.6.8, publié le 31 mai, limite les références RRDP entre origines et place le téléchargement avant l’effacement de l’espace local. La reconstruction dépend désormais d’un indicateur de changement.
  • Le cache conserve un retour rapide fondé sur le résultat mémorisé d’une tentative. Ce résultat n’est pas une nouvelle vérification du fichier, pas plus qu’un hash conforme n’est une autorisation de reconstruire un autre dépôt.

Le correctif de FORT n’est pas un grand ménage du cache. C’est précisément ce qui le rend intéressant. La mémoire du téléchargement reste utile ; c’est la manière dont une reconstruction peut s’appuyer sur elle qui change.

Le problème publié par le projet ne supposait pas de fabriquer un faux snapshot. Les octets pouvaient être authentiques et leur hash correspondre à celui annoncé. Une autorité victime pouvait pourtant voir ses objets disparaître de la sortie locale, sans que sa clé de signature ait été dérobée. Le cas décrit suppose des autorités déléguées sous une même ancre de confiance, pas n’importe quel internaute non authentifié. La bonne question n’était donc pas seulement « le contenu est-il intact ? », mais « dans quel contexte ce contenu et ce succès de téléchargement sont-ils utilisés ? ».

FORT est une initiative de LACNIC et de NIC.MX. Son avis de sécurité classe le problème de cache partagé comme élevé, indique les versions jusqu’à 1.6.7 comme affectées et désigne 1.6.8 comme corrigée. Il s’agit ici d’une lecture des sources au 14 septembre, non d’une attaque reproduite, d’un bilan des installations exposées ou d’un lancement de septembre.

Une opération déplacée, une condition ajoutée

Le code RRDP fixé sur la version 1.6.7 commence le traitement du snapshot par delete_rpp : le répertoire local du point de publication est effacé. Le gestionnaire appelle ensuite cache_download, puis parse_snapshot si le téléchargement renvoie un succès. Ce dernier appel ne dépend pas de la récupération de nouveaux octets pendant cette invocation.

Dans la version 1.6.8, le gestionnaire commence par le téléchargement. Il transmet aussi un indicateur changed. Une erreur de téléchargement provoque une sortie avant cet effacement local. L’effacement, l’analyse du snapshot et la suppression du fichier de snapshot sont regroupés sous la condition changed.

La différence est concrète. Un succès simplement retrouvé dans la mémoire du cache, sans changement signalé, ne déclenche plus à lui seul cette séquence de remplacement. Le correctif agit sur le consommateur du résultat, pas en prétendant que chaque résultat enregistré devient une observation neuve.

La même version vérifie l’origine des références de snapshot et de delta lors de la lecture des métadonnées de notification. Une référence vers une autre origine est rejetée. Encadrer les ressources qu’une notification peut solliciter et encadrer le remplacement d’un répertoire sont deux protections distinctes.

Ce que le cache sait vraiment

Dans les sources du cache de 1.6.8, le client construit l’URI téléchargeable dans le contexte de son ancre de confiance. La table utilise comme clé le chemin local fourni par uri_get_local. Si la tentative appartient à la période récente par rapport au démarrage du cache, le chemin rapide retourne son résultat enregistré.

Il faut être exact jusque dans ce détail : la clé visible dans ce code n’est pas littéralement une simple URL HTTPS globale. Et ce retour rapide ne refait pas un contrôle de présence sur disque.

Cela ne signifie pas que FORT ignore les fichiers. cache_check les vérifie ; un nettoyage retire aussi des entrées dont le fichier a disparu. Le constat porte sur ce retour particulier. Il n’autorise ni à nier les autres vérifications, ni à annoncer un contournement du correctif.

L’avis officiel décrit un enchaînement réparé. La comparaison des sources montre pourquoi le retour mémorisé est désormais consommé sous d’autres conditions. La persistance de ce retour ne prouve pas que l’attaque décrite reste possible dans la version corrigée.

Le téléchargement n’est pas la validation

Le hash conserve son rôle. parse_snapshot compare le fichier au hash attendu avant d’analyser son XML. Rien dans cette enquête ne montre l’acceptation d’un snapshot dont le hash serait incorrect.

Mais l’ordre précis interdit une autre simplification. Dans la branche changed, le gestionnaire efface l’espace de travail, puis appelle parse_snapshot, où se fait la vérification du hash. Télécharger avant d’effacer n’est donc pas, dans cette fonction, valider avant d’effacer.

Ce n’est pas la démonstration d’une perte définitive. Le validateur complet, ses replis, sa récupération et la publication finale de sa sortie n’ont pas été exécutés ici. Cette fonction seule ne prouve pas une transaction conservant toujours le dernier état valide ; elle ne prouve pas non plus qu’une erreur fera perdre des routes aux utilisateurs.

Un hash conforme relie des octets à une empreinte attendue. Il ne remplace ni la validation des signatures et des ressources RPKI, ni les règles limitant les références entre dépôts, ni la décision d’un routeur.

Une frontière logique, pas une machine unique

RFC 9674, publié en décembre 2024 et mettant à jour RFC 8182, impose une politique de même origine pour les références et interdit les redirections entre origines. L’origine correspond au schéma, à l’hôte et au port. Ce n’est pas l’identité d’une entreprise, un compte de connexion ou l’obligation d’utiliser un seul serveur physique.

Un CDN peut donc rester derrière l’origine requise. Le constat de code présenté ici concerne les contrôles des références de snapshot et de delta ; ce n’est pas un audit exhaustif des redirections HTTP.

Conserver le cache a une justification solide. De nombreux clients doivent récupérer un ensemble beaucoup plus restreint de dépôts. Multiplier les transferts ou confondre même origine et machine unique augmenterait la charge sans résoudre proprement le problème de contexte. Le correctif mérite d’être décrit comme une limitation précise, non comme une opposition entre performance et sécurité.

Sources