Résumé

  • En TLS 1.2, un nouveau handshake pouvait se dérouler dans une connexion existante sans prouver qu’il prolongeait la même histoire cryptographique.
  • Le RFC 5746 a conservé les valeurs verify_data du dernier handshake et les a fait vérifier lors de la renégociation.

Quand deux handshakes valides racontent une fausse histoire

L’attaque commençait par une connexion parfaitement légitime, mais établie par l’attaquant. Celui-ci envoyait au serveur des octets applicatifs choisis, puis faisait passer le handshake d’un client victime sur cette connexion déjà protégée. Le client croyait commencer une session avec le serveur ; le serveur pouvait interpréter ce handshake comme une renégociation de la connexion de l’attaquant.

L’attaquant ne pouvait pas ensuite lire le trafic protégé de la victime. Cela ne supprimait pas le préfixe déjà livré. Le serveur pouvait donc voir les données choisies par l’attaquant suivies de requêtes authentifiées de la victime, et les traiter comme une seule interaction. Dans HTTPS, une application qui ne séparait pas correctement les phases pouvait associer ce préfixe à des informations d’identité ou à des cookies transmis plus tard.

Le problème n’était ni un chiffrement brisé ni un certificat falsifié. Chaque handshake possédait ses propres messages Finished valides. Ce qui manquait était la preuve que le nouveau handshake succédait précisément à celui que l’autre extrémité avait observé.

Lier le présent au dernier Finished

Le RFC 5746 a ajouté un indicateur secure_renegotiation et conservé, pour chaque connexion, les verify_data client et serveur du handshake immédiatement précédent. Il ne s’agissait pas simplement d’informations conservées dans un cache de sessions reprenables : elles appartenaient à la connexion active.

L’extension renegotiation_info, de type 0xff01, transportait cette mémoire. Lors du handshake initial, son champ renegotiated_connection était vide. Lors d’une renégociation, le client envoyait sa valeur client_verify_data sauvegardée. Le serveur la comparait à son propre état, puis renvoyait la concaténation des valeurs client et serveur. Le client effectuait à son tour la vérification. Une extension obligatoire absente ou une valeur incohérente provoquait l’abandon fatal du handshake.

L’interprétation éditoriale est nette : la réussite d’un handshake ne suffisait plus. Il devait réussir comme successeur de l’histoire exacte de cette connexion.

Un signal de compatibilité qui n’était pas une suite cryptographique

Certains anciens équipements TLS échouaient face aux extensions inconnues. Le RFC 5746 a donc défini TLS_EMPTY_RENEGOTIATION_INFO_SCSV, codé 0x00,0xFF, dans la liste des suites cryptographiques. Les anciennes implémentations devaient ignorer les suites inconnues ; le signal pouvait ainsi annoncer la prise en charge sans dépendre d’un analyseur d’extensions fiable.

Le SCSV n’était ni une suite négociable ni le mécanisme de liaison des renégociations ultérieures. Il indiquait seulement, lors du premier handshake, la compréhension du dispositif. Si un serveur ne confirmait pas la renégociation sécurisée, le client devait arbitrer entre interopérabilité et garantie contre le raccordement frauduleux. TLS ne permettait pas de distinguer à lui seul un serveur ancien qui refusait toute renégociation d’un serveur dépourvu de la réparation.

De la réparation à la suppression

TLS 1.3 a choisi une autre frontière : la renégociation y est interdite. Un ClientHello reçu plus tard sur une connexion TLS 1.3 doit être rejeté comme message inattendu. Une connexion établie avec une version antérieure doit conserver cette version si elle reçoit un ClientHello TLS 1.3 pendant une renégociation : celle-ci ne permet pas de passer à TLS 1.3. Cette règle ne rend pas équivalents les mécanismes ultérieurs : KeyUpdate et l’authentification post-handshake répondent à des besoins distincts.

Pour TLS 1.2, le RFC 9325 exige que clients et serveurs prennent en charge renegotiation_info, et que le client interrompe la connexion si le serveur ne l’accepte pas. Le RFC 5746 n’a pas résolu toutes les attaques impliquant plusieurs handshakes ; le RFC 9325 traite séparément le secret maître étendu et la famille du triple handshake. Son apport historique est plus précis : la continuité temporelle est devenue une propriété authentifiée, au lieu d’une supposition laissée à l’application.

Sources