Mauvaise compréhension de SSL et de man-in-the-middle

Question

J'ai lu des tonnes de documentation relative à ce problème, mais je n'arrive toujours pas à rassembler toutes les pièces du puzzle. J'aimerais donc poser quelques questions.

1. Je vais tout d'abord décrire brièvement la procédure d'authentification telle que je la comprends, car je peux me tromper à cet égard : Un client établit une connexion, à laquelle un serveur répond par une combinaison de clé publique, de métadonnées et de signature numérique d'une autorité de confiance. Le client décide ensuite s'il fait confiance au serveur, chiffre une clé de session aléatoire avec la clé publique et la renvoie. Cette clé de session ne peut être décryptée qu'avec la clé privée stockée sur le serveur. Le serveur fait cela et la session HTTPS commence.

2. Donc, si j'ai raison ci-dessus, la question est de savoir comment l'attaque man-in-the-middle peut se produire dans un tel scénario ? Je veux dire que même si quelqu'un intercepte la réponse du serveur (par exemple www.server.com) avec la clé publique et a des moyens de me faire croire qu'il est www.server.com, il ne serait toujours pas capable de décrypter ma clé de session sans la clé privée.

3. En ce qui concerne l'authentification mutuelle, s'agit-il uniquement de la confiance du serveur dans l'identité du client ? Je veux dire, le client peut déjà être sûr qu'il communique avec le bon serveur, mais maintenant le serveur veut savoir qui est le client, non ?

4. Et la dernière question concerne l'alternative à l'authentification mutuelle. Si j'agis en tant que client dans la situation décrite, que se passe-t-il si j'envoie un login/mot de passe dans l'en-tête HTTP après l'établissement de la session SSL ? D'après moi, cette information ne peut pas être interceptée car la connexion est déjà sécurisée et le serveur peut s'y fier pour mon identification. Ai-je tort ? Quels sont les inconvénients d'une telle approche par rapport à l'authentification mutuelle (seuls les problèmes de sécurité sont importants, pas la complexité de mise en œuvre) ?

Answer 1

Les attaques de type "Man-in-the-middle" sur SSL ne sont réellement possibles que si l'une des conditions préalables de SSL est rompue. Voici quelques exemples ;

• La clé du serveur a été volée - ce qui signifie que l'attaquant peut se faire passer pour le serveur, et il y a pas du tout que le client doit connaître.

• Le client fait confiance à une AC non fiable (ou à une AC dont la clé racine a été volée) - quiconque détient une clé d'AC fiable peut générer un certificat en se faisant passer pour le serveur et le client lui fera confiance. Avec le nombre d'AC préexistantes dans les navigateurs aujourd'hui, cela peut être un vrai problème. Cela signifie que le certificat du serveur semblerait changer pour un autre certificat valide, ce que la plupart des clients vous cacheront.

• Le client ne prend pas la peine de valider correctement le certificat par rapport à sa liste de CA de confiance - n'importe qui peut créer une CA. Sans validation, "Ben's Cars and Certificates" apparaîtra comme étant tout aussi valide que Verisign.

• Le client a été attaqué et une fausse AC a été injectée dans ses autorités racine de confiance - ce qui permet à l'attaquant de générer n'importe quel certificat qu'il souhaite, et le client lui fera confiance. Les logiciels malveillants ont tendance à faire cela pour, par exemple, vous rediriger vers de faux sites bancaires.

Le point 2 est plutôt désagréable, même si vous payez pour un certificat hautement fiable, votre site ne sera en aucun cas lié à ce certificat. tous CA dans le navigateur du client, car n'importe laquelle d'entre elles peut générer un faux certificat pour votre site qui est tout aussi valide. Elle ne nécessite pas non plus d'accès au serveur ou au client.

Answer 2

Mise à jour 2022

Cette réponse est maintenant dépassée grâce à Transparence des certificats .

Réponse originale

N'importe qui sur la route entre le client et le serveur peut organiser une attaque de type "man in the middle" sur https. Si vous pensez que cela est peu probable ou rare, considérez que il existe des produits commerciaux qui décryptent, scannent et ré-encryptent systématiquement tous trafic ssl à travers une passerelle internet . Ils fonctionnent en envoyant au client un certificat ssl créé à la volée avec les détails copiés du "vrai" certificat ssl, mais signé avec une chaîne de certificats différente. Si cette chaîne se termine par l'une des AC de confiance du navigateur, ce MITM sera invisible pour l'utilisateur. Ces produits sont principalement vendus aux entreprises pour "sécuriser" (policer) les réseaux d'entreprise, et doivent être utilisés en connaissance de cause et avec le consentement des utilisateurs. Techniquement, rien n'empêche les FAI ou tout autre opérateur de réseau de les utiliser. (On peut supposer sans risque que la NSA a au moins une clé de signature de l'AC racine de confiance ).

Si tu sers une page, vous pouvez inclure un en-tête HTTP indiquant avec quelle clé publique la page doit être signée. Cela peut contribuer à alerter les utilisateurs sur le MITM de leur connexion "sécurisée", mais c'est une technique de confiance à la première utilisation. Si Bob n'a pas déjà un enregistrement de la "vraie" clé publique, Mallory réécrit simplement l'en-tête pkp dans le document. La liste des sites web utilisant cette technologie (HPKP) est déprimante. Elle inclut google et dropbox, ce qui est tout à leur honneur. En général, une passerelle d'interception https laisse passer les pages des quelques grands sites de confiance qui utilisent HPKP. Si vous voyez une erreur HPKP alors que vous ne vous y attendez pas, méfiez-vous.

En ce qui concerne les mots de passe, tout ce qui se trouve sur une connexion https est sécurisé par https, sauf le nom de domaine, qui doit être en clair pour que la demande puisse être acheminée. En général, il est recommandé de ne pas mettre les mots de passe dans la chaîne de requête, où ils peuvent traîner dans les journaux, les signets, etc. Mais la chaîne de requête n'est pas visible, sauf si le protocole https est compromis.

Answer 3

Tout d'abord, je vais décrire brièvement la procédure d'authentification telle que je la comprends, je me trompe peut-être sur cette étape. Ainsi, un client établit une connexion et un serveur lui répond en combinant une clé publique, des métadonnées et une signature numérique d'une autorité de confiance.

Le serveur répond avec une chaîne de certificats X.509 et une signature numérique signée avec sa propre clé privée.

Ensuite, le client décide s'il fait confiance au serveur.

Correct.

chiffre une clé de session aléatoire avec la clé publique et la renvoie.

Non. Le client et le serveur s'engagent dans un processus de génération mutuelle de clés de session, dans lequel la clé de session elle-même n'est jamais transmise.

Cette clé de session ne peut être décryptée qu'avec la clé privée stockée sur le serveur.

Non.

Le serveur fait cela

Non.

et ensuite la session HTTPS commence.

Le site TLS/SSL La session commence, mais il y a d'autres étapes avant.

Donc, si je suis correct ci-dessus, la question est de savoir comment l'attaque man-in-the-middle peut se produire dans un tel scénario ?

En se faisant passer pour le serveur et en agissant comme point de terminaison SSL. Le client devrait omettre toute étape d'autorisation. Malheureusement, la seule étape d'autorisation dans la plupart des sessions HTTPS est la vérification du nom d'hôte.

Je veux dire que même si quelqu'un intercepte la réponse du serveur (par exemple www.server.com) avec la clé publique et qu'il me fait croire par un moyen quelconque qu'il est www.server.com, il ne pourra toujours pas décrypter ma clé de session sans la clé privée.

Voir ci-dessus. Il n'y a pas de clé de session à décrypter. La connexion SSL elle-même est sécurisée, elle est à qui vous parlez qui peuvent ne pas être sécurisées.

En ce qui concerne l'authentification mutuelle, le serveur doit-il avoir confiance dans l'identité du client ? Je veux dire que le client peut déjà être sûr qu'il communique avec le bon serveur, mais maintenant le serveur veut savoir qui est le client, non ?

Correct.

Et la dernière question concerne l'alternative à l'authentification mutuelle. Si j'agis en tant que client dans la situation décrite, que se passe-t-il si j'envoie un login/mot de passe dans l'en-tête HTTP après l'établissement de la session SSL ? D'après ce que je vois, cette information ne peut pas être interceptée car la connexion est déjà sécurisée et le serveur peut s'y fier pour mon identification. Ai-je tort ?

Non.

Quels sont les inconvénients de cette approche par rapport à l'authentification mutuelle (seuls les problèmes de sécurité sont importants, pas la complexité de mise en œuvre) ?

La sécurité est aussi grande que le nom d'utilisateur et le mot de passe, qui sont beaucoup plus faciles à divulguer qu'une clé privée.

Answer 4

1. Correct
2. Pas si correct. Dans ce type d'attaque, le serveur intermédiaire reçoit votre demande et l'envoie à la destination en votre nom, puis vous répond avec le résultat. En fait, c'est le serveur "man-in-the-middle" qui établit une connexion sécurisée avec vous, et non le serveur réel avec lequel vous êtes censé communiquer.
3. pourrait être correct
4. Si vous êtes sûr que la connexion sécurisée est fiable, vous pouvez envoyer le nom d'utilisateur et le mot de passe en toute sécurité.

Answer 5

Tout ce que vous avez dit est correct, sauf la partie concernant la clé de session. Le but des AC est de déjouer une attaque de type "man-in-the-middle" - tout le reste est fait par SSL lui-même. L'authentification du client est une alternative au système de nom d'utilisateur et de mot de passe.