Vu l'étape 1, cette faille n'est vraiment pas problématique :
Le client demande la connexion : il envoie des données aléatoires (que l’on appelera ici CR pour Client Random) qui serviront à établir le master secret ainsi que la liste des algorithmes qu’il connait.
L’attaquant reçoit le CR et le transmet au serveur, mais en indiquant qu’il ne connait que RSA (ou DHE, mais cela ne semble pas fonctionner avec ECDHE).
Le serveur envoie à l’attaquant le SR (pour Server Random) et le SID (identifiant de session) qui serviront eux aussi à la construction du master secret, et indique qu’il utilise RSA. Ce message est transmis sans modification au client.
Le serveur envoie son certificat à l’attaquant et l’attaquant transmet son certificat au client.
Notez cette dernière sous-étape : à ce moment-là, le client s'aperçoit que le certificat ne correspond pas au nom du serveur auquel il essaie de se connecter, détecte donc une possible attaque MiTM, et abandonne la connexion.
Cette attaque ne peut donc se faire que dans un des cas suivants :
corruption d'une autorité de certification, pour que le pirate puisse obtenir un certificat reconnu pour le nom du serveur ;
négligence du client, qui accepte de se connecter sans vérifier le certificat du serveur.
Bref, c'est une faille qui semble simplement aggraver un cas classique d'attaque MiTM.
# Pas grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche « Triple poignée de main », faille dans le protocole TLS. Évalué à 3.
Vu l'étape 1, cette faille n'est vraiment pas problématique :
Notez cette dernière sous-étape : à ce moment-là, le client s'aperçoit que le certificat ne correspond pas au nom du serveur auquel il essaie de se connecter, détecte donc une possible attaque MiTM, et abandonne la connexion.
Cette attaque ne peut donc se faire que dans un des cas suivants :
Bref, c'est une faille qui semble simplement aggraver un cas classique d'attaque MiTM.