SSH est-il sécurisé contre MiTM si les empreintes digitales du serveur ne sont pas vérifiées, l'authentification par clé publique est utilisée et la confidentialité n'est pas requise pour ce service?
Lors de la première connexion à un serveur, ssh oblige généralement les utilisateurs à vérifier les empreintes digitales du serveur, puis à mettre en cache les informations. Cela est nécessaire pour empêcher MiTM.
Est-ce un défaut de conception dans SSH qu'un utilisateur doit vérifier manuellement l'empreinte digitale? Je veux dire le cas d'utilisation suivant.
Il y a un serveur. Il y a un client. Le serveur fournit des services personnalisés aux utilisateurs authentifiés. Il est donc de la responsabilité du serveur de vérifier correctement les informations d'identification de l'utilisateur.
Le serveur connaît son empreinte digitale. Supposons que le client (pas ssh one, mais une application basée sur ssh, comme un client GUI pour git) ne veuille pas vérifier l'empreinte digitale car pour ce faire, il devrait obtenir la véritable empreinte digitale d'une manière ou d'une autre, ce qui signifie que l'interface graphique pour cela a à mettre en œuvre.
Le protocole d'authentification est que le client signe le défi fourni par le serveur, le serveur le vérifie puis autorise l'accès. Cela ressemble à une faille de conception: un serveur malveillant peut usurper l'identité d'un utilisateur sur un serveur légitime en effectuant MiTM et en procurant des réponses de l'utilisateur au serveur d'origine.
La solution serait de signer non seulement le défi, mais aussi l'empreinte digitale du serveur. (Voir la réponse acceptée pour l'image de droite) Ensuite, le serveur peut détecter MiTM côté serveur. Bien qu'il ne protège pas d'un serveur malveillant se faisant passer pour un utilisateur.
En bref: ce n'est pas un défaut de conception. Vous venez d'avoir un malentendu sur le design.
Le protocole d'authentification est que le client signe le défi fourni par le serveur, le serveur le vérifie puis autorise l'accès.
Le client ne signe pas de défi fourni par le serveur. Au lieu de cela, le client signe une structure définie dans RFC 4252 section 7 qui inclut comme composant majeur l'identifiant de session. Cet identifiant de session lui-même est le résultat de l'échange de clés comme décrit dans RFC 4253 section 7.2 .
... un serveur malveillant peut usurper l'identité d'un utilisateur sur un serveur légitime en effectuant MiTM et en procurant les réponses de l'utilisateur au serveur d'origine.
Étant donné que le MITM n'a pas accès à la clé privée des clients, il ne peut pas créer une nouvelle signature avec cette clé. Il doit donc trouver un moyen de faire accepter au serveur la signature originale par le client. Et puisque la signature dépend de l'identifiant de session, le MITM devrait établir une connexion SSH entre le client et le MITM et une autre entre le MITM et le serveur qui ont tous les deux le même identifiant de session.
Mais dans l'échange de clés Diffie Hellman, le résultat de l'échange de clés dépend à la fois des données client inconnues du serveur et des données serveur inconnues du client. Puisque le MITM n'a qu'un contrôle sur un côté de chaque connexion, il ne peut pas contrôler le résultat de l'échange de clés et ne peut donc pas contrôler l'identifiant de session.
Par conséquent, l'attaque que vous décrivez ne fonctionnera pas. Le MITM ne peut pas simplement emprunter l'identité du client tant que le serveur authentifie correctement le client. Soit l'authentification échouera car la signature est rompue (ne correspond pas à l'identifiant de session), soit elle échouera car la clé publique n'est pas celle attendue par le serveur (dans le cas où MITM a créé sa propre clé client).
Est-ce un défaut de conception dans SSH qu'un utilisateur doit vérifier manuellement l'empreinte digitale?
Il a des avantages et des inconvénients (surprise!).
Les sites Web utilisent un tiers "de confiance" pour HTTPS. Nous faisons tous confiance à Staat Der Nederlanden, Chunghwa, Atos et à la China Financial Certification Authority pour vérifier votre connexion entre vous et votre banque, non? Parce que c'est exactement ce qu'ils font, et cela s'est avéré mal dans le passé. Mais c'est le meilleur que nous ayons obtenu: nous ne pouvons pas nous attendre à ce que nos mamans téléphonent à la banque pour leur demander leurs empreintes digitales, nous devons donc utiliser ces autorités de certification semi-fiables.
Pour SSH, il est principalement utilisé par les administrateurs système ou d'autres utilisateurs expérimentés, il est donc plus raisonnable de s'attendre à ce qu'ils vérifient l'empreinte digitale, ou au moins à comprendre ce que c'est. Un administrateur soucieux de la sécurité peut le vérifier s'il le souhaite (par exemple, je travaille pour un cabinet de conseil en sécurité informatique et nous vérifions les empreintes digitales avant de nous connecter). Sinon, au moins c'est la confiance à la première utilisation comme Sjoerd l'a déjà mentionné , donc il ne peut pas simplement changer sans que vous le remarquiez. Une attaque doit être présente dès le départ et doit se poursuivre indéfiniment pour qu'elle passe inaperçue.
Cela ressemble à une faille de conception: un serveur malveillant peut usurper l'identité d'un utilisateur sur un serveur légitime en effectuant MiTM et en procurant des réponses par procuration de l'utilisateur au serveur d'origine.
Même chose avec tout autre régime, non? Vous pouvez toujours MitM et proxy du trafic. Dans le cas de ssh, vous obtenez une mauvaise empreinte digitale la première fois ou une alerte de graisse lors de toute connexion ultérieure, et dans le cas de https, vous obtenez un avertissement de certificat.
La solution serait de signer non seulement le défi, mais aussi l'empreinte digitale du serveur. Le serveur peut alors détecter MiTM côté serveur.
Pensez-y bien:
R: Bonjour, serveur SSH de bob.example.com!
B: Salutations, étranger. Voici ma clé publique: abcdef
M: intercepte le message et remplace abcdef par 123456
R: Salut le serveur bob avec la clé publique 123456, je suis Alice avec le mot de passe bz8iuqw45.
M: intercepte le message et change 123456 en abcdef
B: Salut Alice! Vous vous êtes connecté avec succès!
Un attaquant utilisera sa propre clé publique, afin de pouvoir décrypter le trafic. Lors de la transmission des données, ils peuvent remplacer l'empreinte digitale. Vous devrez faire une authentification mutuelle, où le client fournit une clé publique qui est déjà approuvée par le serveur. Ce n'est qu'alors que le serveur sait avec certitude que le client utilise la bonne clé et qu'il n'est pas man-in-the-middled. Mais maintenant, vous avez inversé le problème: maintenant, le serveur doit connaître la bonne empreinte digitale (de la clé publique de l'utilisateur) au lieu de l'utilisateur du serveur. Le problème, la distribution des clés, demeure.
Supposons que le client ne veuille pas vérifier l'empreinte digitale, car pour ce faire, il doit obtenir la véritable empreinte digitale d'une manière ou d'une autre.
Voulez-vous dire qu'il est impossible d'obtenir l'empreinte digitale, sans faire confiance à l'empreinte digitale lors de la connexion? Parce que vous pourriez saisir la véritable empreinte digitale lors de l'installation du serveur, avant de vous connecter via ssh.
J'ai l'impression que certains clients ne vérifient pas du tout les empreintes digitales
Ce serait une vulnérabilité du client. Si vous souhaitez vérifier les empreintes digitales mais que votre client ne le prend pas en charge, vous ne pouvez pas utiliser ces clients. Il est un peu facile de dire "les auteurs du protocole ssh ont tout fait de travers, cela fait que les clients ignorent la sécurité", car comme je l'ai dit, ce schéma par défaut présente des avantages et des inconvénients. Si vous voulez le changer, SSH prend en charge les autorités de certification comme l'a mentionné paj28 .