SSL et incompréhension de l'homme du milieu
J'ai lu des tonnes de documentation sur ce problème, mais je ne parviens toujours pas à rassembler tous les éléments. J'aimerais donc poser quelques questions.
Tout d'abord, je décrirai 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 s'il approuve le 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 une clé privée stockée sur le serveur. C'est ce que fait le serveur, puis la session HTTPS commence.
Donc, si j'ai raison ci-dessus, la question est de savoir comment l'attaque par 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 dispose d'un moyen de me faire penser qu'il est www.server.com, il ne pourra toujours pas déchiffrer ma clé de session sans la clé privée.
S'agissant de l'authentification mutuelle, s'agit-il de la confiance du serveur vis-à-vis de l'identité du client? Je veux dire, le client peut déjà être sûr de communiquer avec le bon serveur, mais maintenant, le serveur veut savoir qui est le client, n'est-ce pas?
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 identifiant/un 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'en servir pour mon identification. Ai-je tort? Quels sont les inconvénients d'une telle approche par rapport à l'authentification mutuelle (seules les questions de sécurité sont importantes, 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 brisée, en voici quelques exemples.
La clé du serveur a été volée - signifie que l'attaquant peut sembler être le serveur, et il y a aucun moyen à la connaissance du client.
Le client fait confiance à une autorité de certification non digne de confiance (ou à une personne dont la clé racine a été volée). Quiconque détient une clé d'autorité de certification approuvée peut générer un certificat prétendant être le serveur et le client lui fait confiance. Avec le nombre d’autorités de certification préexistantes dans les navigateurs d’aujourd’hui, le problème peut être réel. Cela signifie que le certificat de serveur semblerait changer pour un autre certificat valide, ce que la plupart des clients vous cacheront.
Le client ne s'empresse pas de valider le certificat correctement par rapport à sa liste d'autorités de certification approuvées - tout le monde peut créer une autorité de certification. Sans validation, "Ben's Cars and Certificates" semblera aussi valide que Verisign.
Le client a été attaqué et une fausse autorité de certification a été injectée dans ses autorités racine de confiance. Elle permet à l'attaquant de générer le certificat qu'il souhaite et le client lui fera confiance. Les logiciels malveillants ont tendance à le faire, par exemple pour vous rediriger vers de faux sites bancaires.
En particulier, 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 à tous dans le navigateur du client, car aucun des ils peuvent générer un faux certificat pour votre site tout aussi valide. De plus, il n’exige pas d’accès au serveur ni 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 suis trompé sur cette étape. Ainsi, un client commence une connexion et un serveur y répond en combinant une clé publique, des 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 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 participent à un processus de génération de clé de session mutuelle, la clé de session elle-même n'étant jamais transmise.
Cette clé de session ne peut être déchiffrée qu'avec une 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-elle se produire dans un tel scénario?
En se faisant passer pour le serveur et en faisant office de 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 certains moyens, laissez-moi penser qu'il est www.server.com, il ne pourra 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écrypter. La connexion SSL elle-même est sécurisée, c'est à qui vous parlez qui peut ne pas être sécurisée.
S'agissant de l'authentification mutuelle, s'agit-il de la confiance du serveur vis-à-vis de l'identité du client? Je veux dire, que le client peut déjà être sûr de communiquer avec le bon serveur, mais maintenant, le serveur veut savoir qui est le client, n'est-ce pas?
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 identifiant/un mot de passe dans l'en-tête HTTP une fois la session SSL établie? 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’en fier pour mon identification. Ai-je tort?
Non.
Quels sont les inconvénients d'une telle approche par rapport à l'authentification mutuelle (seules les questions de sécurité sont importantes, pas la complexité de la mise en œuvre)?
C'est aussi sécurisé que le nom d'utilisateur/mot de passe, qui sont beaucoup plus faciles à fuir qu'une clé privée.
N'importe qui sur la route entre client et serveur peut mettre en scène l'attaque d'un homme au milieu sur https. Si vous pensez que cela est peu probable ou rare, considérez que il existe des produits commerciaux qui systématiquement décrypter, numériser et rechiffrer tous trafic ssl sur une passerelle internet . Ils travaillent en envoyant au client un certificat SSL créé à la volée avec les détails copiés à partir du "vrai" certificat SSL, mais signés avec une chaîne de certificats différente. Si cette chaîne se termine par l'une des autorités de certification de confiance du navigateur, ce MITM sera invisible pour l'utilisateur. Ces produits sont principalement vendus aux entreprises pour des réseaux "sécurisés" (de police) et doivent être utilisés en connaissance de cause et avec le consentement des utilisateurs. Techniquement, rien n'empêche leur utilisation par les FAI ou tout autre fournisseur de réseau. (Il serait prudent de supposer que NSA possède au moins une clé de signature de l'autorité de certification racine de confiance) ).
Si vous envoyez une page, vous pouvez inclure un en-tête HTTP indiquant avec quelle clé publique la page doit être signée. Cela peut aider à alerter les utilisateurs sur le MITM de leur connexion "sécurisée", mais c'est une technique de confiance lors de la première utilisation. Si Bob ne possède pas déjà l'enregistrement de la "véritable" clé publique, Mallory ne fait que réécrire l'en-tête pkp dans le document. La liste des sites Web utilisant cette technologie (HPKP) est extrêmement courte. Il inclut google et dropbox, à leur actif. En général, une passerelle d'interception https parcourt les pages des quelques grands sites de confiance utilisant 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 traîner dans les journaux, les signets, etc. Cependant, la chaîne de requête n'est pas visible à moins que https ne soit compromis.
- Correct
- Pas si correct. Dans ce type d'attaque, le serveur immédiat reçoit votre demande et l'envoie à votre destination. et ensuite vous répondre avec le résultat. En fait, c’est le serveur intermédiaire 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 approuvé.
- pourrait être correct
- Si vous êtes sûr que la connexion sécurisée est approuvée, vous pourrez alors envoyer un nom d'utilisateur/mot de passe en toute sécurité.
Tout ce que vous avez dit est correct sauf la partie concernant la clé de session. Le but des autorités de certification est de vaincre 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 à un schéma de nom d'utilisateur et de mot de passe.