Résumé

  • Le TLS d'origine chiffrait le second handshake à l'intérieur du premier canal sans lier cryptographiquement les deux négociations.
  • Le RFC 5746 a imposé la preuve du handshake précédent dans renegotiation_info; TLS 1.3 a ensuite supprimé la renégociation.

Un flux, deux provenances

L'attaquant commence par établir sa propre connexion TLS avec le serveur. Il envoie ensuite un préfixe applicatif de son choix, par exemple le début d'une requête. Puis il fait passer le handshake d'une victime dans cette connexion déjà chiffrée. Pour la victime, il s'agit de son premier contact avec le véritable serveur. Pour le serveur, ce même échange ressemble à une renégociation de la session de l'attaquant.

Après le nouveau handshake, l'attaquant ne peut pas lire les données de la victime. Le problème est ailleurs : le serveur peut concaténer le préfixe de l'attaquant et les octets authentifiés de la victime, puis les interpréter comme une seule action. Le chiffrement protège donc chaque portion sans prouver qu'elles ont le même auteur.

Le schéma d'attaque du RFC 5746 distingue trois continuités trop souvent confondues : celle du transport, celle du chiffrement et celle du transcript applicatif. Le maintien de la même connexion TCP ne répond pas à la question décisive : à quel échange antérieur le nouvel état authentifié appartient-il ?

La mémoire cryptographique du canal

Le correctif conserve, pour chaque connexion, le verify_data envoyé par le client et par le serveur dans les messages Finished du handshake immédiatement précédent. L'extension renegotiation_info, de type 0xff01, est vide lors du handshake initial. Elle signale ainsi la prise en charge du mécanisme sans inventer de passé.

Lors d'une renégociation, le ClientHello transporte le verify_data précédent du client. Le ServerHello renvoie la valeur du client suivie de celle du serveur. Chaque partie compare ces données avec sa propre mémoire ; si l'extension manque ou si une valeur diffère, elle interrompt le handshake. Un attaquant qui tente de greffer le premier handshake d'une victime sur une autre connexion ne possède pas la preuve attendue de l'échange antérieur.

Le point subtil est que cette preuve appartient à la connexion et non à une entrée générale de reprise de session. Le second handshake n'est pas déclaré sûr parce qu'il se déroule sous des clés existantes. Il l'est parce qu'il nomme cryptographiquement la négociation dont il prétend être la suite.

Une réparation sous contrainte de compatibilité

Certains anciens serveurs ne respectaient pas la règle qui leur demandait d'ignorer les extensions inconnues. Pour éviter que le déploiement du correctif ne casse immédiatement ces systèmes, le RFC 5746 a ajouté TLS_EMPTY_RENEGOTIATION_INFO_SCSV. Cette valeur ressemble à une suite cryptographique dans le ClientHello, mais elle n'en est pas une et ne peut pas être négociée ; elle signale seulement la prise en charge de la renégociation sûre.

Cette transition laissait pourtant une ambiguïté. Un serveur sans réponse pouvait accepter une renégociation dangereuse, ou bien refuser toute renégociation et être sûr sans savoir le signaler. Le client ne pouvait pas distinguer ces politiques par TLS. Refuser la connexion maximisait la sécurité ; l'accepter préservait davantage d'interopérabilité. L'absence d'une preuve exploitable devenait donc une décision opérationnelle.

TLS 1.3 réduit le problème en supprimant le mécanisme

Le RFC 8446 interdit la renégociation après un handshake TLS 1.3. Un ClientHello reçu hors de sa place attendue provoque la fermeture de la connexion. La mise à jour des clés et l'authentification postérieure au handshake existent encore, mais comme mécanismes séparés et non comme réouverture générale de la négociation.

Le RFC 9325 maintient une ligne nette pour TLS 1.2 : clients et serveurs doivent implémenter renegotiation_info, et le client doit mettre fin à la connexion si le serveur ne l'acquitte pas. Les textes établissent la faille, le correctif et la suppression ultérieure ; ils ne fournissent ni bilan exhaustif des victimes de 2009 ni recensement des déploiements actuels. La conclusion de conception reste solide : un changement d'identité ou de clés doit prouver l'état qu'il hérite, pas seulement circuler dans un canal chiffré.

Sources