Aller au contenu principal

1. Introduction (Introduction)

1. Introduction (Introduction)​

Dans TLS [RFC5246], chaque session a un master_secret calculé comme suit :

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)
                    [0..47];

où le pre_master_secret est le résultat d'un protocole d'échange de clés. Par exemple, lorsque le handshake utilise une suite de chiffrement RSA, cette valeur est générée uniformément au hasard par le client, tandis que pour les suites de chiffrement Ephemeral Diffie-Hellman (DHE), c'est le résultat d'un accord de clé Diffie-Hellman.

Comme décrit dans [TRIPLE-HS], dans les échanges de clés RSA et DHE, un attaquant actif peut synchroniser deux sessions TLS afin qu'elles partagent le même master_secret. Pour un échange de clés RSA où le client n'est pas authentifié, cela est réalisé comme suit. Supposons qu'un client C se connecte à un serveur A. C ne réalise pas que A est malveillant et que A se connecte en arrière-plan à un serveur honnête S et termine les deux handshakes. Pour simplifier, supposons que C et S n'utilisent que des suites de chiffrement RSA.

  1. C envoie un ClientHello à A, et A le transmet à S.

  2. S envoie un ServerHello à A, et A le transmet à C.

  3. S envoie un Certificate, contenant sa chaîne de certification, à A. A le remplace par sa propre chaîne de certification et l'envoie à C.

  4. S envoie un ServerHelloDone à A, et A le transmet à C.

  5. C envoie un ClientKeyExchange à A, contenant le pre_master_secret, chiffré avec la clé publique de A. A déchiffre le pre_master_secret, le rechiffre avec la clé publique de S et l'envoie à S.

  6. C envoie un Finished à A. A calcule un Finished pour sa connexion avec S et l'envoie à S.

  7. S envoie un Finished à A. A calcule un Finished pour sa connexion avec C et l'envoie à C.

À ce stade, les deux connexions (entre C et A, et entre A et S) ont de nouvelles sessions qui partagent le même pre_master_secret, ClientHello.random, ServerHello.random, ainsi que d'autres paramètres de session, y compris l'identifiant de session et, éventuellement, le ticket de session. Par conséquent, la valeur master_secret sera égale pour les deux sessions et sera associée à la fois à C et S avec le même ID de session, même si les identités de serveur sur les deux connexions sont différentes. Rappelons que C ne voit que le certificat de A et n'est pas au courant de la connexion de A avec S. De plus, les clés d'enregistrement sur les deux connexions seront également les mêmes.

Le scénario ci-dessus montre que TLS ne garantit pas que les secrets maîtres et les clés utilisés sur différentes connexions seront différents. Même si l'authentification du client est utilisée, le scénario fonctionne toujours, sauf que les deux sessions diffèrent maintenant à la fois sur les identités du client et du serveur.

Un scénario similaire peut être réalisé lorsque le handshake utilise une suite de chiffrement DHE. Notez que même si le client ou le serveur ne préfère pas utiliser RSA ou DHE, l'attaquant peut les forcer à l'utiliser en n'offrant que RSA ou DHE dans ses messages hello. Les handshakes utilisant des suites de chiffrement Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) sont également vulnérables s'ils autorisent des courbes explicites arbitraires ou utilisent des courbes avec de petits sous-groupes. Contre des adversaires plus puissants, d'autres échanges de clés, tels que Secure Remote Password (SRP) et Pre-Shared Key (PSK), se sont également révélés vulnérables [VERIFIED-BINDINGS].

Une fois que A a synchronisé les deux connexions, puisque les clés sont les mêmes des deux côtés, il peut s'éloigner et transmettre de manière transparente les messages entre C et S, en lisant et en modifiant quand il le souhaite. Dans la littérature sur l'échange de clés, de tels événements sont appelés attaques de partage de clé inconnu (unknown key-share attacks), car C et S partagent un secret mais ils pensent tous les deux que leur secret n'est partagé qu'avec A. En elles-mêmes, ces attaques ne brisent pas l'intégrité ou la confidentialité entre des parties honnêtes, mais elles offrent un point de départ utile à partir duquel monter des attaques d'usurpation d'identité sur C et S.

Supposons que C essaie de reprendre sa session sur une nouvelle connexion avec A. A peut alors reprendre sa session avec S sur une nouvelle connexion et transmettre les messages de handshake abrégés inchangés entre C et S. Puisque le handshake abrégé ne repose que sur le secret maître pour l'authentification et ne mentionne pas les identités du client ou du serveur, les deux handshakes se terminent avec succès, ce qui entraîne les mêmes clés de session et le même journal de handshake. A connaît toujours les clés de connexion et peut envoyer des messages à C et à S.

De manière critique, à la nouvelle connexion, même le journal de handshake est le même sur C et S, déjouant ainsi tout schéma de protection de l'homme du milieu qui repose sur l'unicité des messages finished, comme l'extension d'indication de renégociation sécurisée [RFC5746] ou les liaisons de canal TLS (channel bindings) [RFC5929]. [TRIPLE-HS] décrit plusieurs exploits basés sur de telles attaques de synchronisation de session. En particulier, il décrit une attaque de l'homme du milieu, appelée "triple handshake", qui contourne les protections de [RFC5746] pour casser la renégociation TLS authentifiée par le client après la reprise de session. Des attaques similaires s'appliquent aux mécanismes d'authentification au niveau de l'application qui reposent sur des liaisons de canal [RFC5929] ou sur du matériel de clé exporté depuis TLS [RFC5705].

Le problème de protocole sous-jacent menant à ces attaques est que le secret maître TLS n'est pas garanti d'être unique entre les sessions, car il n'est pas lié contextuellement au handshake complet qui l'a généré. Si nous corrigeons ce problème dans le calcul initial du secret maître, alors toutes ces attaques peuvent être évitées. Cette spécification introduit une extension TLS qui modifie la façon dont la valeur master_secret est calculée dans un handshake complet en incluant le journal des messages de handshake, de sorte que différentes sessions auront, par construction, des secrets maîtres différents. Cela empêche les attaques décrites dans [TRIPLE-HS] et documentées dans la section 2.11 de [RFC7457].

Dernière mise à jour le