Résumé

  • TLS 1.2 permettait une renégociation sur une connexion existante sans lier cryptographiquement la nouvelle négociation à la précédente, ce qui ouvrait la voie à une attaque limitée par injection de préfixe.
  • RFC 5746 a introduit les mécanismes de signalisation et de liaison nécessaires ; TLS 1.3 a supprimé la renégociation. Ni la publication d’un standard ni l’existence d’un correctif dans une bibliothèque ne prouvent toutefois sa présence partout où le protocole est encore utilisé.

Le défaut était une rupture de continuité, pas une clé universelle pour l’attaquant

Dans le modèle TLS 1.2 décrit par les documents de l’IETF, un serveur pouvait accepter une nouvelle négociation sur une connexion déjà établie sans démontrer cryptographiquement que cette négociation appartenait à la même histoire de session. Le problème portait donc sur la continuité entre deux handshakes.

L’attaque décrite par l’IETF est bornée. Un attaquant établit d’abord une connexion TLS, envoie ensuite des octets de préfixe dans le flux applicatif, puis provoque ou exploite une renégociation au cours de laquelle le handshake de la victime est inséré dans la même connexion. Le serveur peut alors traiter les octets précédents comme s’ils précédaient le contexte applicatif de la victime. Cela ne signifie pas que l’attaquant déchiffre arbitrairement toute la session : le mécanisme décrit est une injection de préfixe dans un chemin vulnérable.

Le document RFC 7457 décrit cette famille d’attaques et ses limites. La distinction est importante pour l’imputabilité : le défaut se situait dans la liaison entre états de protocole, tandis que l’impact dépendait aussi du comportement du serveur et de l’application qui consommait le flux.

RFC 5746 a réparé la liaison, avec deux mécanismes distincts

La réparation spécifiée par RFC 5746 ne repose pas sur une simple déclaration générale de compatibilité. Elle distingue le signal de prise en charge de la renégociation sécurisée et la preuve cryptographique reliant la renégociation au handshake précédent.

Lors du handshake initial, l’extension renegotiation_info ou le signal TLS_EMPTY_RENEGOTIATION_INFO_SCSV permet d’indiquer la prise en charge de la renégociation sécurisée. Lors d’une renégociation, les données verify_data issues du handshake précédent sont reprises dans l’information de renégociation afin que le nouveau handshake soit lié au précédent. La propriété recherchée est cette liaison cryptographique : une nouvelle négociation ne doit plus pouvoir être présentée comme indépendante de l’histoire déjà établie.

Cette différence détermine la chaîne de responsabilité. L’IETF peut spécifier le mécanisme et documenter le comportement attendu. Les mainteneurs de bibliothèques doivent l’implémenter ; les fabricants et intégrateurs doivent l’exposer correctement dans leurs produits ; les opérateurs doivent l’activer, retirer les modes vulnérables ou isoler les exceptions ; les propriétaires d’applications doivent vérifier que leurs chemins de connexion ne réintroduisent pas le problème à travers un proxy, un terminateur ou un saut interne.

La publication de RFC 5746 établit donc une correction normative. Elle n’établit pas que toutes les implémentations l’ont adoptée, que tous les équipements l’activent, ou que chaque application dépendante a cessé d’utiliser une voie vulnérable.

Les recommandations ont évolué, mais l’héritage reste une question opérationnelle

RFC 7525 puis RFC 9325 ont maintenu des recommandations sur l’usage de TLS et la gestion des versions anciennes. Elles replacent la renégociation dans un problème plus large de cycle de vie : les protocoles vieillissants peuvent rester présents dans des produits, des équipements spécialisés ou des chemins que l’inventaire central ne décrit pas complètement.

TLS 1.3 a pris une autre voie. Comme le rappelle RFC 8446, TLS 1.3 a supprimé la renégociation et conserve des mécanismes post-handshake plus étroits, qui ne doivent pas être confondus avec une renégociation TLS 1.2. Cette évolution réduit la surface du problème pour les connexions effectivement négociées en TLS 1.3. Elle ne démontre pas, à elle seule, que les anciennes versions ont disparu des terminaisons, des bibliothèques ou des applications en aval.

C’est ici que la correction de protocole devient une question de preuve. Un point d’entrée TLS 1.3 peut coexister avec un saut interne utilisant une ancienne bibliothèque. Un inventaire de serveurs peut omettre une appliance, un service abandonné mais encore joignable, ou une application qui construit sa propre pile de connexions. Une politique qui interdit la renégociation n’est pas la même chose qu’un test démontrant qu’aucun chemin hérité ne l’accepte encore.

Ce qui prouverait une fermeture durable

Une preuve crédible devrait être répartie sur plusieurs surfaces, plutôt que résumée par la date de publication d’un RFC ou par une déclaration de conformité.

  1. Tester les points d’entrée publics. Les tests doivent identifier les versions négociées et le comportement de renégociation, y compris les chemins de compatibilité encore exposés.
  2. Inventorier les bibliothèques et produits. Les équipes doivent relier chaque service à une version de bibliothèque, à un équipement de terminaison et à une configuration effective, pas seulement à une politique théorique.
  3. Vérifier les sauts internes. Les contrôles doivent couvrir les connexions entre services, les proxys, les équilibreurs et les terminaisons qui ne sont pas visibles depuis Internet.
  4. Attribuer les exceptions. Toute ancienne pile maintenue pour compatibilité doit avoir un propriétaire, une justification, une échéance et une mesure compensatoire vérifiable.
  5. Conserver la preuve de retrait. La fermeture doit laisser des traces : résultats de tests répétés, inventaire mis à jour, changements de configuration, retrait d’équipements et validation des chemins applicatifs.

Ces éléments ne doivent pas être confondus. Un test ponctuel ne remplace pas un inventaire ; un inventaire ne prouve pas le comportement effectif ; une configuration conforme sur un serveur frontal ne prouve pas l’état d’un saut interne ; une exception documentée n’est pas une fermeture.

Une responsabilité distribuée, mais pas dissoute

La responsabilité est distribuée parce que le défaut traverse plusieurs couches. Elle ne doit pas pour autant disparaître dans une formule vague selon laquelle « TLS est corrigé ». L’IETF a une responsabilité de spécification et de clarification. Les implémenteurs ont une responsabilité de correction et de compatibilité. Les opérateurs ont une responsabilité de détection, de configuration et de retrait. Les propriétaires d’applications ont une responsabilité sur les chemins et les dépendances qu’ils contrôlent.

L’incertitude publique demeure réelle : les sources examinées ne démontrent ni un déploiement universel de RFC 5746, ni le retrait complet de tous les comportements hérités, ni la configuration actuelle d’un opérateur nommé. Cette limite n’affaiblit pas la correction ; elle fixe ce que l’on peut honnêtement conclure.

La question pratique pour les responsables n’est donc pas seulement : « Quel standard avons-nous publié ou quel correctif avons-nous installé ? » Elle est : pouvons-nous montrer, surface par surface, que les comportements vulnérables ont disparu des points d’entrée, des bibliothèques, des équipements, des sauts internes et des chemins applicatifs — et que les exceptions restantes ont un propriétaire et une date de sortie ?