SSL et malentendu de l'homme du milieu

J'ai lu des tonnes de documentation liée à ce problème, mais je n'arrive toujours pas à rassembler tous les éléments, alors j'aimerais poser quelques questions.

1. Tout d'abord, je vais décrire brièvement la procédure d'authentification telle que je la comprends, car je peux me tromper à cet égard: un client démarre une connexion, à laquelle un serveur répond avec une combinaison de clé publique, de métadonnées et de signature numérique d'un autorité de confiance. Ensuite, le client prend la décision si elle 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échiffrée qu'avec la clé privée stockée sur le serveur. Le serveur fait cela, puis la session HTTPS commence.

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

3. Parlant de l'authentification mutuelle, est-ce une question de confiance du serveur sur l'identité du client? Je veux dire, la cliente peut déjà être sûre qu'elle 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 une fois la session SSL établie? Selon moi, ces informations ne peuvent pas être interceptées 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 la mise en œuvre)?

Les attaques man-in-the-middle sur SSL ne sont vraiment possibles que si l'une des conditions préalables de SSL est rompue, voici quelques exemples;

• La clé du serveur a été volée - signifie que l'attaquant peut sembler être le serveur et que le client n'a aucun moyen de le savoir.

• Le client fait confiance à une autorité de certification non fiable (ou à une autorité dont la clé racine a été volée) - quiconque détient une clé de l'autorité de certification de confiance peut générer un certificat se faisant passer pour le serveur et le client lui fera confiance. Avec le nombre d'autorités de certification préexistantes dans les navigateurs aujourd'hui, cela peut être un réel problème. Cela signifie que le certificat du serveur semble 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 d'autorités de certification de confiance - n'importe qui peut créer une autorité de certification. En l'absence de validation, «Ben's Cars and Certificates» apparaîtra tout aussi valable que Verisign.

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

Surtout le n ° 2 est plutôt méchant, même si vous payez pour un certificat hautement fiable, votre site ne sera en aucun cas verrouillé sur ce certificat, vous devez faire confiance à toutes les autorités de certification dans le navigateur du client, car chacune d'entre elles peut générer un faux certificat pour votre site qui est tout aussi valide. Il ne nécessite pas non plus d'accès au serveur ou au client.

Tout d'abord, je vais décrire brièvement la procédure d'authentification telle que je la comprends, peut-être que je me trompe sur cette étape. Ainsi, un client démarre une connexion et un serveur y répond en combinant la clé publique, certaines métadonnées et la 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 prend la décision si elle fait confiance au serveur

Correct.

crypte 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 de clé de session mutuelle dans lequel la clé de session elle-même n'est jamais transmise du tout.

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

Non.

Le serveur fait cela

Non.

puis la session HTTPS commence.

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

Donc, si j'ai raison ci-dessus, la question est de savoir comment l'attaque de l'homme du milieu peut se produire dans un tel scénario?

En se faisant passer pour le serveur et en agissant comme le 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 une 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 une clé publique, puis avec quelques moyens, laissez-moi penser qu'il est www.server.com, il ne pourrait toujours pas déchiffrer ma clé de session sans la clé privée.

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

Parlant de l'authentification mutuelle, est-ce une question de confiance du serveur sur 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? Comme je le vois, ces informations ne peuvent pas être interceptées 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 d'une telle approche par rapport à l'authentification mutuelle (seuls les problèmes de sécurité sont importants, pas la complexité de la mise en œuvre)?

C'est aussi sûr que le nom d'utilisateur / mot de passe, qui sont beaucoup plus faciles à divulguer qu'une clé privée.

N'importe qui sur la route entre le client et le serveur peut mettre en scène une attaque d'homme au milieu sur https. Si vous pensez que c'est peu probable ou rare, considérez qu'il existe des produits commerciaux qui déchiffrent, analysent et rechiffrent systématiquement tout le trafic SSL via une passerelle Internet.. Ils fonctionnent en envoyant au client un certificat ssl créé à la volée avec les détails copiés à partir du "vrai" certificat ssl, mais signé avec une chaîne de certificats différente. Si cette chaîne se termine par l'une des CA de confiance du navigateur, ce MITM sera invisible pour l'utilisateur. Ces produits sont principalement vendus aux entreprises pour des réseaux d'entreprise «sécurisés» (policiers) et devraient être utilisés avec la connaissance et l'assentiment des utilisateurs. Techniquement cependant, rien n'empêche leur utilisation par les FAI ou tout autre opérateur de réseau. (Il serait prudent de supposer que la NSA a au moins une clé de signature de l'autorité de certification racine approuvée ).

Si vous diffusez une page, vous pouvez inclure un en-tête HTTP indiquant la clé publique avec laquelle la page doit être signée. Cela peut aider à alerter les utilisateurs du MITM de leur connexion "sécurisée", mais c'est une technique de confiance lors de la première utilisation. Si Bob n'a pas déjà un enregistrement de la "vraie" broche de clé publique, Mallory réécrit simplement l'en-tête pkp dans le document. La liste des sites Web utilisant cette technologie (HPKP) est terriblement courte. Il comprend google et dropbox, à leur honneur. Habituellement, une passerelle d'interception https parcourt 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 sur une connexion https est sécurisé par https, à l'exception du 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 de mots de passe dans la chaîne de requête, où ils peuvent rester dans les journaux, les signets, etc. Mais la chaîne de requête n'est pas visible à moins que https ne soit compromis.

1. Correct
2. Pas si correct. Dans ce type d'attaque, le serveur itermediate reçoit votre demande et l'envoie à destination en votre nom. et ensuite vous répondre avec le résultat. En fait, c'est le serveur de l'homme du milieu qui établit une connexion sécurisée avec vous et non le serveur que vous êtes censé communiquer. c'est pourquoi vous DEVEZ toujours vérifier que le certificat est valide et fiable.
3. pourrait être correct
4. Si vous êtes sûr que la connexion sécurisée est approuvée, il serait prudent d'envoyer un nom d'utilisateur / mot de passe.

Tout ce que vous avez dit est correct, sauf la partie sur la clé de session. L'intérêt des autorités de certification est de vaincre une attaque d'intermédiaire - tout le reste est fait par SSL lui-même. L'authentification client est une alternative à un schéma de nom d'utilisateur et de mot de passe.