SSL et malentendu de l'homme du milieu


91

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)?

Réponses:


103

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.


4
Il existe également des outils comme sslstrip , qui tenteront de réécrire de manière transparente les liens https en liens http.
mpontillo

3
Un autre point concernant la vérification des certificats est que le client doit vérifier le nom d'hôte. Il ne suffit pas de vérifier que le certificat est authentique, il doit être émis par l'entité à laquelle vous voulez parler (voir ici et ici ). En ce qui concerne sslstrip, c'est finalement à l'utilisateur de vérifier s'il souhaite utiliser SSL / TLS malheureusement (bien que HSTS puisse aider).
Bruno

Puis-je écrire un plugin Chrome (ou tout autre navigateur d'ailleurs) qui intercepte les données AVANT que le navigateur les crypte?
Rosdi Kasim

Une autre raison est «l'abus de confiance», comme dans le numéro de TürkTrust.
ceremcem

1
@Remover Pas vraiment ... # 1 est la clé privée sur le serveur, associée à la véritable clé publique. Dans ce scénario, vous parleriez au vrai serveur mais quelqu'un d'autre pourrait décrypter le trafic en étant au milieu. Ils ne peuvent pas modifier le certificat. # 2 implique l'envoi d'un certificat entièrement différent, émis par une autorité de certification «de confiance» qui apparaîtra comme étant légitime pour le client. L'attaquant peut alors envoyer des requêtes proxy en votre nom et voir les messages de cette façon. Les deux aboutissent à un compromis, mais le n ° 1 est sous votre contrôle. # 2, malheureusement, ne l'est pas.
base le

17

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.


Merci pour ton explication. La seule chose que je n'ai pas comprise, c'est pourquoi vous avez dit qu'un client n'envoie pas de clé de session à un serveur? Eh bien, peut-être que j'ai utilisé une terminologie erronée, ici cette donnée est appelée "secret pré-maître", mais de toute façon, n'est-elle pas envoyée par le client et décryptée avec la clé privée du serveur?
Vadim Chekry

1
@VadimChekry Le secret pré-maître n'est pas la clé de session. Il s'agit de l'une des nombreuses données utilisées pour générer la clé de session, indépendamment aux deux extrémités. Le processus est décrit dans la RFC 2246.
Marquis of Lorne

1
@Chris Vous êtes beaucoup moins vulnérable, mais l'usurpation d'adresse IP est possible. Rien ne remplace la vérification vous-même de l'identité du pair dans le certificat.
Marquis of Lorne

1
+1 C'est une assez bonne réponse, pour la plupart. Cependant, certains points manquent d'explication avec des réponses en un mot. Vous pourriez en faire une réponse définitive si vous deviez développer et / ou élaborer sur lesdits points (c'est-à-dire au lieu de «non», vous pourriez brièvement mentionner ce qui se passe réellement ) dans le corps principal. Cela clarifierait vraiment certaines choses. Merci.
voix du

1
@ tjt263 Le premier «non» explique ce qui se passe réellement. Les deux «non» suivants se réfèrent à la même idée fausse qui a produit le premier «non» et ont la même explication. Le «non» suivant et final se réfère à «ai-je tort» et il se réfère aux informations que vient de citer le PO. Il est donc difficile de comprendre ce qui, selon vous, manque réellement ici.
Marquis of Lorne

17

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.


Mais cela signifie que cet équipement MITM (celui qui déchiffre / scanne et re-crypte le trafic) doit avoir accès à l'une des CA de confiance, n'est-ce pas? (pour "simuler" le certificat du serveur). Disons que cela arrive. Ensuite, quelqu'un arrête cela, les informations deviennent publiques, et il y aura un scandale dans la presse et le certificat CA sera supprimé de tous les navigateurs, n'est-ce pas? Je veux dire, idéalement ...
jazzcat

2
Non non. L '«inspection SSL» sur la passerelle doit créer et signer des certificats à la volée, mais elle n'a pas besoin d'un certificat racine pour ce faire. Il a un certain cert intermédiaire, qui a une chaîne. Le fait que la racine de la chaîne soit approuvée ou non par votre navigateur détermine si vous verrez une erreur de certificat. Au travail, on nous a demandé d'installer le certificat racine fortinet afin que nos navigateurs ne donnent pas d'erreurs de certificat. Mais si la chaîne s'est terminée avec un certificat déjà approuvé, c'est transparent.
bbsimonbb

Un collègue de travail utilisait une compréhension limitée de la raison pour laquelle ces techniques MITM de réseau d'entreprise sont une mauvaise idée pour Google de forcer SSL - Pouvait-il réellement avoir une once d'exactitude?
EmSixTeen

1
Désolé je ne comprends pas la question!
bbsimonbb

2
  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.

À propos de 2 - Je suppose que le client vérifie minutieusement les métadonnées envoyées par le serveur lors de la procédure d'établissement de la connexion et que le client ne fait pas confiance à TOUS les certificats. Un tel scénario ne serait-il pas possible si - a) un client ne fait pas ce que j'ai dit ci-dessus, ou b) un homme du milieu a quelque part un certificat signé par une autorité de certification de confiance?
Vadim Chekry

1
Il arrive très rare que le serveur intermédiaire envoie un certificat valide, l'année dernière, cela s'est produit avec Comodo CA si je me souviens bien. Mais normalement, s'il s'agit d'une connexion de confiance, elle est complètement sécurisée.
Boynux

1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.