Résumé

  • Finished vérifie le transcript de la poignée de main courante au moyen du secret négocié ; les données applicatives antérieures à une renégociation ne font pas, de ce seul fait, partie de cette preuve.
  • RFC 5746 relie la nouvelle négociation à la précédente grâce aux anciens verify_data. L’application doit encore décider quel principal possède les octets en attente, puis prouver autorisation et résultat.

Une preuve neuve au milieu d’un flux ancien

Une connexion transporte déjà des données protégées. Un second ClientHello apparaît. Le serveur peut demander un certificat client, négocier de nouvelles clés et accepter un Finished valide. Vu depuis la bibliothèque TLS, l’opération est réussie.

Mais Finished n’a jamais été conçu comme une signature de toute la conversation. Dans RFC 5246, son verify_data dépend du secret maître et des messages de handshake échangés. Il confirme que les deux côtés partagent le même transcript de négociation et le même état de clés. Les octets applicatifs qui précèdent la renégociation n’entrent pas dans ce transcript.

L’écart permettait une composition trompeuse. Un intermédiaire pouvait établir sa propre connexion, envoyer un préfixe applicatif, puis faire suivre la nouvelle négociation d’une victime. Le serveur observait une authentification ultérieure valide et pouvait interpréter le préfixe de l’intermédiaire et la suite de la victime comme un même flux. La cryptographie locale n’était pas fausse ; la relation entre les deux histoires n’était pas prouvée.

Une socket ne possède pas une identité immuable

TLS 1.2 distinguait l’état courant de l’état en attente. La négociation prépare les algorithmes et secrets ; ChangeCipherSpec active l’état en attente ; Finished teste alors le résultat sous les nouvelles protections.

Cette mécanique précise quel état protège les enregistrements suivants. Elle ne décide pas si une requête commencée avant le changement doit être attribuée à une identité obtenue après. Le descripteur de socket demeure identique, mais la base d’autorité à l’intérieur de ce contenant peut évoluer.

Les tampons applicatifs compliquent encore la frontière. Un parseur peut avoir reçu la moitié d’une commande sous un principal anonyme, puis la moitié suivante sous un certificat client. Sans identifiant de génération TLS attaché aux octets ou à la requête, le résultat « client authentifié » se propage vers un travail plus ancien qu’il n’a jamais autorisé.

Le lien rétrospectif de RFC 5746

La mise à jour Secure Renegotiation transforme la continuité supposée en relation vérifiée. Lors de la négociation initiale, le client signale son support au moyen de renegotiation_info ou de TLS_EMPTY_RENEGOTIATION_INFO_SCSV, et le serveur répond avec une valeur vide. Lors d’une renégociation, l’extension transporte les anciens verify_data client et serveur.

Le nouveau handshake doit donc démontrer qu’il connaît la sortie du handshake précédent. Si les valeurs ne correspondent pas à la connexion réellement détenue, la renégociation est refusée. Ce petit champ rattache cryptographiquement deux négociations au lieu de faire confiance à leur présence sur la même socket.

Il faut pourtant distinguer capacité et exécution. La prise en charge de l’extension ne prouve pas qu’une politique autorise la renégociation. La présence du SCSV dans un ClientHello ne prouve pas qu’un second handshake a eu lieu. Un reçu utile doit montrer le signal, la réponse, les valeurs antérieures attendues, la comparaison et l’issue de cette occurrence.

La continuité cryptographique n’accorde pas l’autorisation

Après la réparation, l’application doit toujours régler ses propres frontières. Que faire d’une commande commencée avant un changement de principal ? L’abandonner, la terminer sous l’ancienne identité ou imposer un nouveau message complet ? RFC 5746 ne choisit pas.

Une terminaison TLS qui exporte seulement le principal le plus récent expose le service amont à une confusion temporelle. Le service devrait recevoir une génération de sécurité, une identité et un intervalle d’octets ou de messages. Une politique explicite doit gouverner toute transition.

RFC 5929 offre des channel bindings utilisables par certaines applications. Là encore, produire une valeur liée au canal et l'utiliser correctement sont deux preuves différentes. Le protocole applicatif doit l'intégrer dans son propre échange et vérifier le résultat.

EMS ne recoud pas la même couture

RFC 7627, Extended Master Secret, dérive le secret maître d’un hash du transcript. Elle répond notamment aux problèmes de session hash et de triple handshake. Sa relation n’est pas celle de RFC 5746.

EMS lie un secret maître à son handshake. Secure Renegotiation lie un nouveau handshake à la connexion précédente au moyen des anciens Finished. Mettre les deux sous une case « durcissement TLS » rend impossible de savoir quelle relation a réellement été vérifiée.

Une trace d’audit devrait donc séparer le support, la négociation EMS, la négociation Secure Renegotiation, la valeur de rattachement et la génération d’identité produite. Aucun drapeau unique ne porte tout ce sens.

TLS 1.3 supprime le second handshake, pas la dette d’inventaire

TLS 1.3 ne permet plus la renégociation. L’architecture retire ainsi cette couture mobile particulière. Cela ne prouve pas que les points de terminaison ont quitté TLS 1.2. Un service peut accepter les deux versions ; un proxy peut recevoir TLS 1.3 et parler TLS 1.2 en amont.

RFC 9851 gèle l’extension ordinaire de TLS 1.2, mais ne désactive aucun listener. La migration a besoin d’un inventaire, de la politique effectivement chargée, des négociations observées, des propriétaires de dépendances et de canaris applicatifs.

Le bon registre de conversation conserve : identifiant et Finished initiaux ; plages de données de cette génération ; déclencheur de renégociation ; signal Secure Renegotiation ; comparaison des valeurs antérieures ; nouveau certificat ; activation d’état ; nouveau Finished ; mappage de principal ; frontière de requête ; autorisation ; commit et résultat externe.

Cette proposition est une analyse opérationnelle de BTW, pas un format imposé par RFC 5246. Elle protège une règle : une preuve forte garde le périmètre de ce qu’elle a réellement observé.

Sources