Résumé

  • Le 13 mai 2008, Debian corrigea un générateur aléatoire propre à son paquet OpenSSL. La mise à jour empêchait la création future de clés prévisibles, mais les clés SSH, OpenVPN, DNSSEC et X.509 déjà produites demeuraient lisibles, copiables et acceptables par des systèmes non corrigés — voire par des systèmes jamais vulnérables.
  • La véritable remise en état associait plusieurs pouvoirs distincts: corriger le code, reconnaître les clés couvertes, en générer de nouvelles, authentifier leur distribution, supprimer les anciennes autorisations ou révoquer les certificats, puis vérifier que chaque partie utilisatrice refusait désormais l’ancien secret.

Deux temps sous un même mot

La formule « OpenSSL est corrigé » décrivait exactement une chose: après installation du nouveau paquet, le prochain appel au générateur n'emprunterait plus la voie défectueuse. Elle ne décrivait pas l'état des clés fabriquées depuis septembre 2006.

C'est là que l'incident Debian rompt avec l'image rassurante du correctif. Une clé faible n'était pas nécessairement corrompue au sens du format. Sa partie publique se chargeait correctement. Sa signature pouvait être vérifiée. Un certificat pouvait rester dans sa période de validité et porter une signature d'autorité de certification parfaitement régulière. La faiblesse appartenait au passé invisible de la clé: le secret avait été choisi dans un ensemble beaucoup trop petit.

L'avis DSA-1571-1 ne se contenta donc pas d'ordonner une mise à niveau. Debian recommanda de recréer tout matériau cryptographique généré par les versions concernées à partir de 0.9.8c-1. L'avis ajouta une réserve plus sévère pour DSA: une clé DSA utilisée sur un système affecté pouvait être compromise par l'aléa de la signature, même si sa génération initiale avait été saine.

Ubuntu formula la frontière géographique avec justesse. La panne directe touchait Debian et ses dérivés. Un autre système pouvait toutefois recevoir une clé faible créée ailleurs et lui accorder une autorisation. L'origine du logiciel ne suffisait plus à définir le périmètre; il fallait suivre la biographie de l'identifiant.

Le petit univers caché derrière une grande clé

Le dossier Debian #363516 commence en avril 2006 par un problème de bruit sous Valgrind. Certaines lectures de mémoire non initialisée dans le générateur provoquaient des alertes. Les échanges du dossier montrent la discussion technique et précisent ensuite que le changement vulnérable effectivement compilé entra avec 0.9.8c-1, lorsque le fichier modifié fut placé sur le chemin de construction utilisé.

La documentation SSLkeys de Debian décrit le résultat opérationnel: le processus défectueux dépendait essentiellement du PID. Pour trois classes d'architecture et 32 767 valeurs possibles, elle donne 98 301 flux candidats dans ce modèle. Pour des tailles et types de clés courants, il devenait possible de préparer les candidats et d'identifier la clé privée correspondant à une clé publique observée.

Ce chiffre n'est ni un recensement des clés faibles ni un bilan d'exploitation. Les applications n'appelaient pas toutes OpenSSL de la même façon; les tailles et architectures variaient; les listes de blocage ne couvraient pas chaque cas. Le chiffre montre néanmoins le renversement économique. La sécurité d'une clé publique suppose que sa moitié privée ne puisse pas être retrouvée à partir de l'information distribuée. Ici, l'information publique permettait de choisir dans un catalogue calculable.

La clé conservait son apparence de rareté après avoir perdu la rareté réelle qui fondait son autorité.

Debian suspendit l'acceptation après avoir réparé le code

La réaction de l'infrastructure Debian est une preuve de mécanisme particulièrement nette. Quelques minutes après l'avis, le projet désactiva l'authentification SSH par clé publique sur ses propres machines. Les transferts automatiques, déclenchements de construction et accès d'administration dépendant de clés devaient attendre une vérification ou un remplacement.

Si l'installation du paquet avait suffi, cette suspension aurait été inutile. Elle fut nécessaire parce que le serveur continuait de reconnaître des identifiants créés avant la correction.

DSA-1576-1 ajouta le paquet openssh-blacklist et l'outil ssh-vulnkey. Les clés utilisateur connues comme faibles pouvaient être rejetées localement. Les clés hôte pouvaient être régénérées, après confirmation. Mais le déplacement de l'autorité ne suivait pas un seul sens.

Pour une clé hôte, le serveur changeait d'identité et le client affichait l'avertissement célèbre annonçant que l'identification de l'hôte avait changé. Cet avertissement ne constituait pas un défaut d'ergonomie à contourner. Il protégeait précisément le droit du client de ne pas croire une nouvelle clé sans l'avoir confirmée par un canal fiable.

Pour une clé utilisateur, le détenteur créait une nouvelle paire puis devait pousser la partie publique vers chaque serveur. L'ancienne ligne devait être retirée de tous les fichiers authorized_keys. Ajouter la nouvelle clé sans supprimer l'ancienne augmentait le nombre de moyens d'entrer; cela ne révoquait rien.

Ainsi, le paquet, la liste noire, la nouvelle paire, la preuve de l'empreinte et le fichier d'autorisation appartenaient à des acteurs différents. Les appeler ensemble « le correctif SSH » aurait masqué les endroits où l'ancien pouvoir survivait.

La liste noire connaissait ses limites

La faiblesse offrait aux défenseurs une occasion rare: puisque des familles de clés pouvaient être énumérées, un programme destinataire pouvait comparer la clé présentée à un corpus connu et la refuser. Cela transforma une analyse publique en veto exécutable.

Le veto n'était pourtant ni global ni omniscient. Debian parlait d'un rejet « lorsque cela est possible ». Ubuntu expliquait que la réponse Unknown (no blacklist information) de ssh-vulnkey ne signifiait pas « sain ». Elle signifiait que le corpus ne permettait pas de conclure. En cas de doute sur la provenance, la recommandation restait de détruire la clé et d'en créer une autre.

DSA-1576-2 montra pourquoi cette prudence était indispensable. La première version de l'outil pouvait ignorer des entrées authorized_keys commençant par des options telles qu'une commande forcée ou l'interdiction du transfert de port. Une clé compromise pouvait donc être acceptée par le serveur tout en échappant au rapport. En juin, les notices Ubuntu étendirent encore les formats, les tailles RSA et les entrées prises en charge.

Ce n'est pas une condamnation des listes de blocage. Pour les clés couvertes, elles donnaient à chaque serveur une défense rapide, y compris sur un système dont OpenSSL n'avait jamais été vulnérable. Elles pouvaient également empêcher qu'une vieille clé faible soit réintroduite plus tard. Leur autorité légitime demeurait bornée à la preuve disponible: refuser le connu, déclarer franchement l'inconnu, ne jamais transformer une absence de correspondance en certificat de sûreté.

Chaque protocole possédait sa propre porte de sortie

Le défaut commun ne produisit pas une procédure commune de révocation.

Dans SSH, la clé utilisateur tirait son pouvoir du fichier distant qui l'autorisait. La preuve de retrait était un échec d'authentification sur chaque serveur significatif. La clé hôte tirait son pouvoir du repère conservé par les clients; son remplacement exigeait une nouvelle empreinte authentifiée.

Dans OpenVPN, une clé partagée devait être remplacée de manière coordonnée sur tous les pairs. Pour une architecture à certificats, il fallait encore gérer émission, distribution et rejet de l'ancien certificat. USN-612-3 insistait sur les clés créées pour d'autres machines: elles devaient être recherchées là où elles avaient été installées.

Dans X.509, une nouvelle clé privée et un nouveau certificat ne rendaient pas automatiquement l'ancien inutilisable. L'émetteur pouvait publier une révocation conformément à son infrastructure; le serveur devait déployer la nouvelle chaîne; les clients devaient consulter ou recevoir un état suffisamment récent. RFC 5280 décrit la validation et les listes de révocation, mais l'existence de cette mécanique ne prouve pas que chaque client l'exécute à temps.

Dans DNSSEC, une clé pouvait faire partie d'une délégation signée et d'états mis en cache. Le roulement devait respecter le protocole et les délais de propagation. Dans l'automatisation, une clé pouvait vivre dans une image, une sauvegarde, un robot de déploiement ou chez un partenaire dont l'équipe d'origine ignorait l'existence.

L'unité pertinente n'était donc pas la machine corrigée. C'était la lignée complète de l'identifiant: générateur, clé, copies, certificats, autorisations, caches et parties utilisatrices.

La validité ne décidait plus de la légitimité

Une preuve SSH mathématiquement correcte montrait seulement que le demandeur possédait le secret correspondant à la clé publique offerte. Elle ne pouvait pas dire si ce secret était imprévisible, volé, partagé ou encore autorisé. Avec une clé Debian faible, un attaquant capable de reconstruire le secret pouvait produire une preuve valide. Le calcul fonctionnait; la prémisse d'exclusivité avait disparu.

La grille de lecture publiée par Lu Heng sur la primauté du code en fonctionnement éclaire ce point, à condition de ne pas en faire une source historique. L'avis Debian, le paquet corrigé ou la révocation d'un certificat restaient des instructions ou des preuves. Le refus devenait réel dans le serveur SSH, le pair VPN ou le client PKI qui exécutait sa règle. La dépendance technique à Debian ne donnait pas au projet un interrupteur universel sur toutes les copies distribuées.

À l'inverse, une plateforme non vulnérable ne pouvait invoquer sa pureté logicielle si sa configuration acceptait une clé importée. La souveraineté pratique sur l'accès se trouvait au point de décision local. Elle imposait une responsabilité: conserver un veto et savoir sur quelles informations il reposait.

Quatre registres pour fermer l'incident

Un inventaire sérieux aurait relié quatre registres. Le premier indiquait la provenance: date et lieu de génération, paquet, bibliothèque, algorithme, taille, architecture et éventuel générateur indépendant. Le deuxième suivait la distribution: copies privées, certificats, serveurs, authorized_keys, known_hosts, pairs VPN, images, sauvegardes et partenaires.

Le troisième liait ancienne et nouvelle empreinte, canal d'authentification, responsable et échéance. Il distinguait la création d'un remplaçant de son déploiement. Le quatrième consignait le refus: l'ancienne clé échoue, l'ancien certificat est rejeté par les clients testés, l'ancien secret VPN n'ouvre plus la session, et toute exception est nommée et expire.

La conformité au correctif appartient au premier registre. La clôture de l'incident appartient au quatrième.

Limites des preuves

Les sources officielles établissent le défaut, la période, les familles d'applications et les mesures recommandées. Elles ne donnent pas un nombre complet de clés produites ou exploitées. Les 98 301 flux ne décrivent pas chaque appel d'application. Unknown n'est ni une preuve de faiblesse ni une preuve de sûreté. Les dates de fichiers peuvent être altérées par une sauvegarde ou une horloge erronée. La régénération automatique dépendait du paquet et du choix administratif. La réémission d'un certificat ne garantit pas que tous les clients aient consulté la révocation.

La conclusion étayée reste plus précise: le générateur corrigé protégeait les créations futures; l'autorité ancienne ne disparaissait que là où elle était retrouvée puis refusée.

Sources