Résumé

  • wolfSSL 5.9.2 a signalé une faille grave limitée aux compilations avec support RPK : une clé publique brute non négociée pouvait remplacer X.509 et contourner la vérification de chaîne. Le correctif rétablit X.509 par défaut et refuse toute forme reçue différente du type convenu.
  • RFC 7250 définit RPK comme un type de certificat TLS à part entière. Il transporte un unique SubjectPublicKeyInfo DER. La preuve cryptographique établit la possession de la clé privée, mais n’apporte ni émetteur, ni sujet signé, ni durée de validité, ni extensions X.509.
  • L’exploitation sûre exige deux traces distinctes : la preuve que la bonne forme a été négociée, puis la preuve qu’une autorité extérieure associe encore cette SPKI au bon service, appareil ou rôle. Une connexion réussie ne démontre aucune des deux à elle seule.

Le mauvais contrat de confiance a été exécuté

Le bulletin de wolfSSL 5.9.2 décrit CVE-2026-55960 sans ambiguïté. Si HAVE_RPK était activé, une clé publique brute pouvait être acceptée alors que les pairs n’avaient pas choisi ce type de certificat. Le chemin de décodage de la clé n’avait pas de chaîne X.509 à contrôler ; il pouvait donc aboutir sans la vérification de confiance attendue pour le certificat.

Le périmètre compte. RPK est désactivé dans une compilation autonome par défaut, mais inclus avec --enable-all. Les sources ne donnent ni nombre d’exploitations ni intervalle complet de versions vulnérables. La conclusion étayée est plus précise : la forme des octets reçus a pris le pouvoir sur le régime que la négociation avait autorisé.

Le correctif inverse cette priorité. En l’absence de négociation alternative, la forme attendue est X.509. Le client compare le type du certificat serveur reçu au type sélectionné ; le serveur fait l’équivalent pour un certificat client. Une clé brute non négociée devient un écart de type et provoque UNSUPPORTED_CERTIFICATE. La pull request ajoute des essais de non-régression dans les deux sens.

Cette modification donne une définition utile du contrôle : le logiciel ne doit pas déduire la politique du document qu’il parvient à parser. Il doit d’abord appliquer la décision du handshake, puis lancer seulement le validateur compétent pour la forme choisie.

Une SPKI n’est pas un certificat amputé

RFC 7250 enregistre Raw Public Key avec la valeur 2 et introduit client_certificate_type et server_certificate_type. Les pairs annoncent les types qu’ils savent fournir ou traiter ; une préférence commune est retenue. Il s’agit d’un contrat explicite, pas d’une heuristique sur le premier octet du message.

Dans le mode RPK, le message Certificate sert de conteneur à une unique structure SubjectPublicKeyInfo encodée en DER. Elle donne l’algorithme, ses paramètres éventuels et les bits de la clé. C’est le noyau que l’on trouve normalement dans un certificat, sans le reste du certificat.

TLS 1.3 conserve expressément ce mécanisme. RFC 8446 inclut RawPublicKey(2) et limite la liste à une seule entrée SPKI lorsque ce type a été négocié. La règle par défaut reste X.509v3, sauf choix explicite d’une autre forme.

Deux conséquences se répondent. Quand RPK a été choisi, l’absence de chaîne n’est pas une erreur à réparer en inventant un certificat. Quand X.509 est attendu, une SPKI bien formée ne doit pas bénéficier d’un chemin plus court. La paire « type négocié, forme reçue » est l’objet de contrôle.

Le handshake prouve la possession ; le nom vient d’ailleurs

CertificateVerify peut démontrer que le pair possède la clé privée correspondant à la clé publique transmise. La signature couvre le transcript du handshake et Finished confirme l’état cryptographique partagé. Cela répond à une question forte mais étroite : l’interlocuteur contrôle-t-il le secret associé à cette SPKI dans cette négociation ?

Le résultat ne dit pas que la clé est celle de capteur-17, du service de paiement ou de l’administrateur d’un site. RFC 5280 aide à mesurer ce qui manque. Dans X.509, la signature de l’autorité certifie une association entre clé publique et sujet. Le corps signé porte aussi émetteur, sujet, numéro de série, période de validité et extensions. Encore faut-il valider la chaîne et la politique de nom ; un certificat n’accorde pas automatiquement un droit applicatif. Mais ces assertions sont absentes d’une SPKI seule.

RFC 7250 impose donc un mécanisme hors bande qui lie la clé à l’entité qui la présente. Il demande aussi de vérifier l’état de ce lien. Le second impératif interdit de confondre une empreinte autrefois juste avec une identité toujours valable.

Une base de confiance RPK doit au moins conserver l’identité canonique, le rôle, le service ou le pair concerné, la SPKI exacte, l’auteur de l’affectation, la date d’effet, l’échéance éventuelle, le prédécesseur, le successeur et l’état de retrait. Elle doit aussi savoir quels vérificateurs ont reçu chaque génération et lesquels refusent désormais l’ancienne clé.

Les bibliothèques exposent la frontière sans choisir l’autorité

La documentation de wolfSSL demande d’activer RPK, de configurer les types acceptés et de fournir un callback qui authentifie la clé hors de TLS. Son exemple TLS 1.3 avec un serveur GnuTLS établit l’interopérabilité, mais indique que le pair n’a pas été vérifié tant que cette logique applicative n’existe pas. Une session chiffrée et une identité acceptée sont deux jalons.

GnuTLS rend le registre extérieur encore plus visible. Son API peut retrouver une clé par hôte et service, distinguer l’absence d’entrée d’une clé différente et attacher une expiration ou un backend sur mesure. La documentation prévient que la vérification X.509 ordinaire ne peut pas authentifier une clé brute dépourvue de corps de certificat ; une comparaison hors bande ou une politique de continuité de clé est nécessaire.

Ces interfaces fournissent des points d’exécution. Elles ne désignent pas l’autorité qui a commissionné la clé, n’assurent pas que le callback est effectivement appelé et ne décident pas du privilège accordé ensuite. Un drapeau de compilation prouve une capacité. Il ne prouve ni la négociation, ni la fraîcheur du registre, ni la portée de l’autorisation.

DANE remplace une chaîne par une autre chaîne de décisions

DANE constitue une option explicitement citée par RFC 7250. RFC 6698 permet à un enregistrement TLSA protégé par DNSSEC d’associer un service DNS à un certificat ou à sa SPKI, directement ou par empreinte. Le nom et la clé peuvent ainsi être liés sans prendre une chaîne de certification classique comme source de l’association.

Le client doit toutefois valider DNSSEC, comprendre l’usage TLSA, le sélecteur et le type de correspondance, puis comparer le bon objet. Un enregistrement publié mais jamais consulté ne possède aucune autorité d’acceptation chez le client.

Le renouvellement met en scène plusieurs horloges. RFC 7671 recommande de publier d’abord la nouvelle association, d’attendre l’expiration des caches, de déployer la nouvelle clé ou le nouveau certificat, puis de retirer les associations devenues inutiles. Pendant la transition, plusieurs visions cohérentes peuvent coexister. Il faut donc mesurer la génération visible par chaque vérificateur et limiter explicitement la période où deux clés sont admises.

Pour un appareil contraint, l’horloge peut être celle du firmware. RFC 7925 présente RPK comme une entrée dans la cryptographie à clé publique sans coût complet du certificat et de la PKI. Mais la clé du pair ou son empreinte doit être fournie avant l’échange. Sur un équipement appelé à vivre dix ans, la simplicité du handshake reporte l’effort vers l’enrôlement et la mise à jour logicielle.

Une connexion verte doit livrer sept réponses

Une preuve exploitable sépare : la politique configurée ; les types offerts ; le type sélectionné ; la forme réellement reçue ; la preuve de possession de clé ; la source extérieure qui lie la SPKI à un nom et son état ; enfin le droit applicatif et l’opération autorisée.

tls_ok=true écrase ces différences. Le bit peut être vrai après un RPK non négocié, une empreinte périmée, un callback absent ou un rôle trop large. À l’inverse, le rejet d’une SPKI valide peut être le comportement exact si le pair attendait X.509 ou si le registre extérieur ne la reconnaît plus.

La primauté du code en exécution, telle que formulée par Heng Lu, éclaire ce point sans remplacer les faits du protocole. Le RFC définit les sens, l’IANA attribue les numéros, DNS publie éventuellement l’association et la configuration annonce une intention. Seul le processus vivant exécute le veto : il impose le type négocié, consulte l’autorité extérieure et borne l’usage applicatif. Le correctif de 2026 est important parce qu’il a restauré ce veto.

Limites de la preuve

Le dossier public établit le défaut, son périmètre fonctionnel et la réparation. Il ne permet pas d’affirmer une exploitation, un nombre de déploiements exposés ou la première version affectée. Il n’établit pas non plus que RPK serait intrinsèquement inférieur à X.509.

Une RPK correctement négociée et reliée à un registre protégé peut être adaptée à un parc maîtrisé. X.509, lui aussi, peut être mal validé. La règle générale est plus exigeante : aucune forme d’identité ne doit hériter de l’acceptation de l’autre tout en échappant à ses contrôles.

Sources