6. Security Considerations (Considérations relatives à la sécurité)

6.1. Triple Handshake Preconditions and Impact (Conditions préalables et impact du triple handshake)

Une façon de monter une attaque de triple handshake est décrite dans la Section 1, avec une mention des mécanismes de sécurité qui se brisent en raison de l'attaque ; une discussion plus approfondie et des diagrammes peuvent être trouvés dans [TRIPLE-HS]. Ici, une discussion plus approfondie est présentée sur les conditions préalables et l'impact de l'attaque.

Pour monter une attaque de triple handshake, il doit être possible de forcer le même secret maître sur deux sessions différentes. Pour que cela se produise, deux conditions préalables doivent être remplies :

Le client, C, doit être prêt à se connecter à un serveur malveillant, A. Dans certains contextes, comme le web, cela peut être facilement réalisé, car un navigateur peut être invité à charger du contenu à partir d'une origine non fiable.
Le secret pré-maître doit être synchronisé sur les deux sessions. C'est particulièrement facile à réaliser avec les échanges de clés RSA et DHE, mais dans certaines conditions, les échanges de clés ECDHE, SRP et PSK peuvent également être exploités à cet effet.

Une fois que le secret maître est synchronisé sur deux sessions, toute propriété de sécurité qui repose sur l'unicité du secret maître est compromise. Par exemple, un exportateur TLS [RFC5705] ne fournit plus une clé unique liée à la session en cours.

La reprise de session TLS repose également sur l'unicité du secret maître pour authentifier les pairs qui reprennent. Par conséquent, si une session synchronisée est reprise, les pairs ne peuvent pas être sûrs de l'identité de l'autre, et l'attaquant connaît les clés de connexion. Clairement, une condition préalable à cette étape de l'attaque est que le client et le serveur prennent en charge la reprise de session (soit via l'identifiant de session, soit via des tickets de session [RFC5077]).

De plus, dans un handshake abrégé synchronisé, toute la transcription (qui inclut les valeurs verify_data) est synchronisée. Ainsi, après un handshake abrégé, les liaisons de canal comme "tls-unique" [RFC5929] n'identifieront plus la connexion de manière unique.

La synchronisation des verify_data dans les handshakes abrégés sape également les garanties de sécurité de l'extension d'indication de renégociation [RFC5746], réactivant une faille d'injection de préfixe similaire à l'attaque de renégociation [Ray09]. Cependant, dans une attaque de triple handshake, le client voit le certificat du serveur changer au cours de différents handshakes complets. Par conséquent, une condition préalable pour monter cette étape de l'attaque est que le client accepte différents certificats à chaque handshake, même si leurs noms communs ne correspondent pas. Avant la découverte de l'attaque de triple handshake, c'était un comportement répandu, au moins parmi certains navigateurs Web ; de tels navigateurs étaient donc vulnérables à l'attaque.

L'extension de secret maître étendu contrecarre les attaques de triple handshake dès leur première étape en garantissant que différentes sessions aboutissent nécessairement à des valeurs de secret maître différentes. Par conséquent, toutes les propriétés de sécurité reposant sur l'unicité du secret maître devraient maintenant tenir. En particulier, si une session TLS est protégée par l'extension de secret maître étendu, il est sûr de la reprendre, d'utiliser ses liaisons de canal et de permettre des changements de certificat lors de la renégociation, ce qui signifie que tous les certificats sont contrôlés par le même pair. Une analyse symbolique du protocole cryptographique justifiant l'extension de secret maître étendu apparaît dans [VERIFIED-BINDINGS].

6.2. Cryptographic Properties of the Hash Function (Propriétés cryptographiques de la fonction de hachage)

Les hachages de session de deux sessions différentes doivent être distincts ; par conséquent, la fonction Hash utilisée pour calculer le session_hash doit être résistante aux collisions. En tant que tel, les fonctions de hachage telles que MD5 ou SHA1 NE SONT PAS RECOMMANDÉES.

Nous observons que la fonction Hash utilisée dans le calcul du message Finished doit déjà être résistante aux collisions pour que l'extension d'indication de renégociation [RFC5746] fonctionne, car une collision significative sur les messages de handshake (et donc sur le verify_data) peut réactiver l'attaque de renégociation [Ray09].

La fonction de hachage utilisée pour calculer le hachage de session dépend de la version du protocole TLS. Toutes les suites de chiffrement actuelles définies pour TLS 1.2 utilisent SHA256 ou mieux, tout comme le hachage de session. Pour les versions antérieures du protocole, seuls MD5 et SHA1 peuvent être supposés être pris en charge, et ce document n'exige pas que les implémentations héritées ajoutent la prise en charge de nouvelles fonctions de hachage. Dans ces versions, le hachage de session utilise la concaténation de MD5 et SHA1, comme dans le message Finished.

6.3. Handshake Messages Included in the Session Hash (Messages de handshake inclus dans le hachage de session)

Le session_hash est destiné à englober toutes les informations de session pertinentes, y compris la négociation de la suite de chiffrement, les messages d'échange de clés et les identités du client et du serveur. Le hachage est nécessaire pour calculer le secret maître étendu et doit donc être disponible avant les messages Finished.

Ce document définit le session_hash pour couvrir tous les messages de handshake jusqu'au message ClientKeyExchange inclus. Pour les suites de chiffrement TLS existantes, ces messages incluent tout le contenu significatif de la nouvelle session -- CertificateVerify ne change pas le contenu de la session. En même temps, cela permet de calculer le secret maître étendu immédiatement après le secret pré-maître, de sorte que les implémentations peuvent supprimer le secret pré-maître temporaire de la mémoire le plus tôt possible.

Il est possible que de nouvelles suites de chiffrement ou extensions TLS incluent des messages supplémentaires entre ClientKeyExchange et Finished qui ajoutent un contexte de session important. Dans de tels cas, certaines des garanties de sécurité de cette spécification peuvent ne plus s'appliquer et de nouvelles attaques de l'homme du milieu peuvent être possibles. Par exemple, si le client et le serveur prennent en charge l'extension de ticket de session [RFC5077], le hachage de session ne couvre pas le nouveau ticket de session envoyé par le serveur. Par conséquent, un homme du milieu peut être en mesure d'amener un client à stocker un ticket de session qui n'était pas destiné à la session en cours. Les attaques basées sur ce vecteur ne sont pas encore connues, mais les applications qui stockent des informations supplémentaires dans les tickets de session au-delà de celles couvertes par le hachage de session nécessitent une analyse minutieuse.

6.4. No SSL 3.0 Support (Pas de prise en charge de SSL 3.0)

La version 3.0 du protocole Secure Sockets Layer (SSL) [RFC6101] est un prédécesseur du protocole TLS, et elle est également vulnérable aux attaques de triple handshake, ainsi qu'à d'autres vulnérabilités découlant de son utilisation de constructions cryptographiques obsolètes qui sont maintenant considérées comme faibles. SSL 3.0 a été déprécié [RFC7568].

La contre-mesure décrite dans ce document repose sur une extension TLS et ne peut donc pas être utilisée avec SSL 3.0. Les clients et les serveurs implémentant ce document DEVRAIENT refuser les handshakes SSL 3.0. S'ils choisissent de prendre en charge SSL 3.0, les sessions résultantes DOIVENT utiliser le calcul du secret maître hérité, et les considérations d'interopérabilité de la Section 5.4 s'appliquent.