Résumé

  • Whois 1.124 est passé en production le 27 août ; quatre jours plus tard, RIPE NCC a publié la version 1.124.1, dont l’unique modification consiste à ne retenir que le certificat signataire pour l’authentification par certificat client.
  • Le correctif public limite la liste de certificats pairs au certificat terminal, placé à l’index zéro, et ajoute un test négatif : un deuxième certificat lié à un autre mainteneur ne doit pas autoriser sa mise à jour.
  • RIPE NCC dit n’avoir trouvé aucune preuve d’exploitation. Il manque encore un reçu public qui borne ce résultat par versions, période, interfaces, couverture des journaux, volumes agrégés, rapprochement avec les historiques d’objets et seuil de notification.

Entre les deux mises en production, il ne s’est écoulé que quatre jours. Whois 1.124 est arrivé le 27 août. Le 31, RIPE NCC a annoncé 1.124.1 en expliquant qu’un seul comportement changeait : l’authentification par certificat client ne devait plus considérer que le certificat signataire. La phase habituelle de deux semaines dans l’environnement de préproduction n’a pas été observée, car il s’agissait de corriger une vulnérabilité signalée la semaine précédente.

Cette décision opérationnelle est défendable. Maintenir une faille connue pour préserver la symétrie du calendrier aurait confondu discipline et rituel. Le correctif devait être rapide. Mais l’avis contient aussi une conclusion distincte : RIPE NCC n’a trouvé aucun élément montrant une exploitation.

Une conclusion négative ne vaut ni aveu, ni preuve d’incident. Elle doit être rapportée telle quelle. Elle devient toutefois pleinement vérifiable seulement lorsque son périmètre est connu.

Le défaut se situe dans la sélection de l’identité

Le certificat client n’est pas une couche décorative de TLS dans RIPE Database. La documentation décrit un mécanisme de mise à jour REST : l’utilisateur produit un certificat X.509 et une clé privée, publie le certificat dans un objet key-cert, puis référence cet objet dans l’attribut auth: d’un mainteneur. Lors d’une requête, le serveur rapproche la signature du certificat enregistré. Le texte précise même que Whois ne valide pas la chaîne de confiance de l’autorité de certification ; il vérifie la signature par rapport au certificat publié.

L’autorité pertinente est donc celle du certificat rattaché au mainteneur. Elle ne devrait pas se propager à chaque certificat transporté dans une chaîne présentée par le pair.

Le commit public 504fccd515ca, daté du 31 août et intitulé laconiquement « Multiple certificates », donne à voir la correction. L’extracteur transforme le tableau des certificats pairs en objets X.509, puis applique .limit(1). Un commentaire identifie l’élément zéro comme certificat terminal — le certificat signataire qui représente l’identité de la connexion. Le point de diagnostic qui affiche les certificats emploie désormais le même extracteur, au lieu de parcourir séparément le tableau brut.

Le test ajouté est plus instructif qu’une longue formule. Un certificat autorise OWNER-MNT. Un second est associé à ANOTHER-MNT. Les deux figurent dans le magasin de test ; la connexion utilise le certificat du propriétaire, puis tente de modifier un objet protégé par l’autre mainteneur. Le résultat attendu est un refus. Autrement dit, présenter un certificat supplémentaire ne doit jamais ouvrir une seconde identité de maintenance.

Ce test fixe la règle nouvelle. Il ne prouve pas qu’une telle opération a réussi en production, qu’un attaquant a existé, qu’un objet a été touché ou qu’une chaîne concrète était malveillante.

« Aucune preuve » a besoin d’un dénominateur

Le dépôt permet de contrôler le correctif : retenir le certificat terminal, écarter les autres pour l’identité et refuser le scénario inter-mainteneurs. L’évaluation de l’exposition porte sur un autre ensemble de faits. À partir de quelle version l’ancien comportement était-il possible ? Jusqu’à quel instant ? La recherche a-t-elle couvert uniquement les mises à jour REST, ou aussi l’affichage de diagnostic et d’autres consommateurs de l’extracteur ?

Il faut également connaître la matière analysée. Quels journaux enregistraient l’authentification par certificat ? Quelle était leur durée de conservation ? Permettaient-ils de distinguer une présentation simple d’une chaîne comportant plusieurs certificats ? Les requêtes acceptées ont-elles été rapprochées des versions d’objets et des notifications de mise à jour ? Quel résultat aurait entraîné l’information d’un mainteneur ?

Ces questions ne réclament ni certificats bruts, ni identités, ni mode d’emploi offensif. Elles demandent le dénominateur de l’assurance publique.

RIPE NCC dispose d’un argument de proportionnalité sérieux, mais ancien. Son étude de septembre 2024 sur la suppression des mots de passe MD5 recensait seulement 29 mainteneurs faisant référence à un key-cert X.509 non expiré, pour quelques mises à jour authentifiées de cette manière par an. Une voie peu utilisée peut se prêter à une vérification exhaustive. Mais ce chiffre n’est pas celui d’août 2026, et un petit volume n’indique pas, à lui seul, que toutes les tentatives étaient observables.

La politique de divulgation responsable impose, elle aussi, une retenue légitime. Les chercheurs sont priés de garder le détail secret jusqu’à la résolution ; RIPE NCC promet d’agir rapidement et peut publier, au cas par cas, un rapport après la correction d’un problème majeur. L’avis 1.124.1 et le test public respectent déjà la séquence essentielle : réparer, puis montrer la limite de contrôle. Une note méthodologique peut compléter l’ensemble sans révéler la méthode d’exploitation.

Un reçu d’évaluation, sans secrets

Le reçu devrait commencer par les versions affectées et deux dates : première exposition possible en production et fin du déploiement correctif. Il énumérerait ensuite les interfaces et types d’opérations examinés, en séparant mises à jour REST, requêtes, diagnostic et autres méthodes d’authentification.

La couverture probatoire vient après : familles de journaux, durée de conservation, champs de corrélation et lacunes significatives. Des nombres agrégés suffisent pour les requêtes avec certificat, les présentations à plusieurs certificats, les acceptations et refus, ainsi que les périmètres uniques de mainteneurs ou d’objets. Pour protéger une population rare, on peut regrouper les faibles volumes ; un zéro réel doit néanmoins rester un zéro explicite.

Le rapprochement est le cœur du reçu. Chaque événement atypique doit pouvoir être relié à l’historique d’un objet et à sa notification. Les issues doivent avoir des catégories stables : trafic de test attendu, requête rejetée, mise à jour autorisée, événement non résolu ou modification non autorisée confirmée. Le public n’a besoin ni du nom du mainteneur, ni du contenu de l’objet. Il doit pouvoir constater que l’univers examiné a été fermé.

Enfin, le document porterait une date de revue, un responsable, un critère de notification et un historique de correction. Si de nouvelles données changent le diagnostic, une version suivante remplacerait la conclusion sans effacer la précédente.

Rien ne permet d’affirmer que ces éléments n’existent pas en interne. Le constat plus étroit suffit : ils ne sont pas attachés à l’assurance publique. Un reçu bref rendrait cette assurance reproductible sans transformer la transparence en fuite de sécurité.

Sources