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