Alors que je faisais quelques recherches sur la vulnérabilité de SSH aux attaques de type MITM, je suis tombé sur ce petit article. L'auteur y explique pourquoi ce protocole, avec une authentification à clef publique, est résistant à ces attaques...
Si j'ai bien compris, il explique en gros que lors d'une MITM, deux connexions sont crées (une client-attaquant et une attaquant-serveur), et que chacune de ces connexion a un identifiant différent (simple conséquence du fait que l'attaquant scinde l'échange de clef Diffie-Hellman en 2, les clef de chaque connexion sont nécessairement différentes et l'identifiant de connexion dépend de la clef). L'auteur dit que si le client signe ses messages (avec sa clef privée) en utilisant l'identifiant de connexion, c'est un problème pour l'attaquant car le serveur connait un autre identifiant et rejetera donc la signature.
Mais pourquoi ?? Qu'est-ce qui empêche l'attaquant de déchiffrer le message du client (possible puisque le client le prend pour le serveur), faire ce qu'il veut avec, le signer à son tour avec le bon identifiant de connexion, et avec sa propre clef privée, puis le renvier au serveur qui n'y verra que du feu puisqu'il prend l'attaquant pour le client ?
L'auteur, lui, conclue « so public-key authentication has somewhat unexpected side effect of preventing MITM. »
J'ai pas lu l'article, mais je dirais plutôt que quand tu inities une connexion SSH par clefs publiques avec un serveur, le serveur t'envoie sa clef publique la première fois. Donc si une personne tente un MITM par la suite, il ne pourra pas tant qu'il ne possède pas la clef privée du serveur, ce qui de toute façon serait la fin de la sécurité de l'ensemble.
Le seul moment où la solution est vulnérable, c'est lors de la première connexion quand on demande au client d'accepter la clef publique du serveur. Si ce n'est pas la bonne machine, c'est foutu !
Oui je le comprends bien, mais il me semblait que l'article parlait précisément de la première connexion... Dans le cas des connexions suivantes le client et le serveur se "connaissent" et il n'y a même pas besoin de l'identifiant de connexion pour s'assurer que tout aille bien. À moins que ?
J'ai parcouru en vitesse, et si j'ai bien compris, il y a une sorte de challenge dans lequel il y a une information de session que l'attaquant ne peut pas connaître.
Mais l'article n'est pas bien clair...
L'idée de base est de savoir que l'attaquant cherche à se faire passer pour le client envers le serveur et de se faire passer pour le serveur envers le client.
Ainsi tout débute avec l'algorithme de Diffie-Hellman. C'est en fait grâce à celui-ci qu'il ne peut pas il y avoir de HDM.
Ensuite si tu connais le fonctionnement du chiffrement à clef publique et après avoir lu l'exemple d'Alice et Bob de l'algorithme ci-dessus tu devrais comprendre l'ensemble de la méthode.
Là où Diffie-Hellman intervient, c'est pour qu'en cas de MITM, le client et le serveur ont nécessairement un identifiant de connexion différent.
L'auteur semble tirer avantage de cette dichotomie par une sorte de "challenge" comme l'a souligné elalitte, mais je ne comprends pas pourquoi l'attaquant serait désarmé face à ce challenge alors qu'il a visiblement toutes les cartes en main...
Je remets l'exemple donné en lien, car je le trouve très clair :
1) Alice et Bob choisissent un nombre premier p et une base g. Dans notre exemple, p=23 et g=3
2) Alice choisit un nombre secret a=6
3) Elle envoie à Bob la valeur g^a [mod p] = 3^6 [23] = 16
4) Bob choisit à son tour un nombre secret b=15
5) Bob envoie à Alice la valeur g^b [mod p] = 3^15 [23] = 12
6) Alice peut maintenant calculer la clé secrète : (g^b [mod p])^a [mod p] = 12^6 [23] = 9
7) Bob fait de même et obtient la même clé qu'Alice : (g^a [mod p])^b [mod p] = 16^15 [23] = 9
g et p sont connus par tout le monde, même les attaquants.
a est connu seulement de Alice, et b seulement de Bob. Donc la seule méthode pour l'attaquant, s'il souhaite retrouver les nombres a et b, est de calculer le logarithme discret de g^a et de g^b. Problème : en pratique c'est impossible.
Donc une possibilité est de se placer entre Alice et Bob (l'homme du milieu) : (citation Wikipedia)
"[...] un attaquant peut [...] intercepter la clé g^a envoyée par Alice et envoyer à Bob une autre clé g^a', se faisant passer pour Alice. De même, il peut remplacer la clé g^b envoyée par Bob à Alice par une clé g^b', se faisant passer pour Bob. L'attaquant communique ainsi avec Alice en utilisant la clé partagée g^(ab') et communique avec Bob en utilisant la clé partagée g^(a'b), Alice et Bob croient communiquer directement.
Alice et Bob croient ainsi avoir échangé une clé secrète alors qu'en réalité ils ont chacun échangé une clé secrète avec l'attaquant, l'homme du milieu."
Citation : revan
L'auteur semble tirer avantage de cette dichotomie par une sorte de "challenge" comme l'a souligné elalitte, mais je ne comprends pas pourquoi l'attaquant serait désarmé face à ce challenge alors qu'il a visiblement toutes les cartes en main...
En effet tu as raison, il n'y a aucun challenge réel. À moins que l'on puisse dire que calculer le logarithme discret pour retrouver les clefs secrète en soit un.
« Je remets l'exemple donné en lien, car je le trouve très clair »
Tu ne fais ici qu'illustrer le protocole de Diffie-Hellman et dire comment procéder à une attaque MITM ; mais ça je le sais déjà, il n'y a pas de confusion, et ça n'a rien de spécifique à SSH, ni ne parle de signature à clef publique, ni n'explique en quoi SSH serait résistant à une attaque MITM (au contraire).
Comme je l'ai dis plus haut, ce qu'apporte Diffie-Hellman c'est de forcer, en cas de MITM, que le client et le serveur aient deux identifiant de connexion différents (alors qu'ils sont sensés avoir le même en situation normale). Il n'est a priori pas nécessaire de se pencher plus près de cette phase du protocole SSH.
Là où réside la confusion (et encore une fois, ça ne me semble toujours pas clair), c'est... pourquoi l'auteur dit-il que SSH est résistant au MITM ? Dans son exemple, il semble dire que le serveur peut se rendre compte qu'il ne s'adresse pas directement au client, grâce à un "certificat" exploitant l'identifiant de connexion. Mais l'attaquant pourrait très bien fausser ce certificat...
Non, il n'y a pas d'autorité de certification qui intervienne dans l'article... il me semble que ça ne serait pas pertinent vis-à-vis des arguments qu'il expose. Ou alors il n'est vraiment pas clair
je suis interressé par cette article, sympa à lire.
J'reprend la pertinence de zornel :
1) Alice et Bob choisissent un nombre premier p et une base g. Dans notre exemple, p=23 et g=3 2) Alice choisit un nombre secret a=6
l'attaque du milieux, nous sommes d'accord, vient du faite que il connaitrait p et g. on le voit dans la boucle car c'est ainsi que se comporte par defaut le ssh.
logique de mass... comme toujours en sécurité informatique... permettant a tous client d'initier la connexion.
nous pouvons configurer, pas encore fait mais sa ne serait tarder, votre article m'as aider dans se sens. retirer l'etape 1 par default post installation des clés.
sachant que le protocole version 2 (plus commune), tiens ses clés suivantes:
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
manque plus qu'à voir comment operer. j'vous tiens au courant
la fin de l'exo, serais l'incapacité d'un putty non configurer d'initier la connexion.
Avant de poster, demandez-vous si ce que vous allez dire apporte quelque chose au sujet. Si votre message n'apporte rien, vous ferez perdre du temps à tout le monde et le sujet pourrait dévier ou devenir difficile à suivre.
Aussi, vérifiez la date du topic. Le déterrage de topic nuit au bon fonctionnement du forum et est interdit. Utilisez les boutons pour dire merci. Si le topic date de plus de deux mois sans réponses, mieux vaut ne pas répondre. Si vous avez une question similaire, créez plutôt votre propre sujet en détaillant votre contexte
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script