客户端身份验证是为了服务器的利益。防止中间人是一个不同的问题。

如果密钥交换使用带有服务器签名的 DH（相对于客户端已知的公钥），则客户端受到保护，不会受到中间人的影响：客户端对它应该是谁有一个强烈的概念正在与之交谈，并且服务器的签名可防止攻击者以任何方式冒充服务器（例如，作为“中间人”，这只是一种特定的冒充）。

没有客户端身份验证，服务器不知道谁在联系它。协议的其余部分（例如SSL/TLS）仍将在以下意义上提供针对攻击的保护：在整个会话期间它将是同一个客户端，并且任何其他方都不能监视数据内容或在未检测到的情况下更改数据大大地。因此，避免了“中间人”（例如：充当中继的攻击者，动态解密和重新加密数据），因为客户端已经验证了来自服务器的签名，并且因此使用了“正确的”Diffie-Hellman 密钥，使任何攻击者都无法进行密钥交换。

客户端身份验证作为签名，由客户端使用自己的私钥计算并对应于服务器已知的公钥，可以帮助防止在客户端不（愚蠢地）检查的狡猾情况下出现中间人来自服务器的签名。没有什么可以阻止这个愚蠢的客户端连接到假服务器，因为它什么都不检查，因此可以随意盗用。但是，客户端身份验证足以让服务器确保如果客户端完全与它对话，那么它将以安全的方式进行。

这里的关键是定义问题。什么是“中间人”？在这种情况下，攻击者冒充预期的对等点（为了成为“真正的中间人”，攻击者就客户端而言冒充服务器，而就服务器而言，则冒充客户端）。这仅在存在“预期对等方”的情况下才有意义。如果服务器不关心谁在联系它，那么就没有“中间人”的概念。

在通常的 HTTPS 场景中，客户端通过密码进行身份验证：客户端需要确保一开始就与正确的服务器通信（使用服务器证书），因为客户端不希望将其密码发送给任何人。服务器只想保持连续性：如果它通过 SSL 隧道获得了正确的密码，那么隧道是好的，并且会继续如此。

嗯......是的，好处就是：验证客户端。

在今天的主要用例中，服务器的证书用于对服务器进行身份验证（“威瑞信说这真的是 amazon.com”）并设置加密（防止窥探和中间人）。

因为它很少使用，所以人们不会想到对客户端进行身份验证的能力。这样做有一个实际原因，即客户端“用户”（人）可以从任意数量的客户端“机器”（计算机）访问服务器，如果使用客户端密钥，则需要将它们安全地分发给所有客户端。他们，客户端机器需要相对信任，等等。但是确实存在使用（SSL）客户端身份验证有意义的场景。

如果智能卡曾经流行起来，那么你会到处看到它。但他们没有。（或者只是还没有，我真的不知道）。

仅进行服务器身份验证将确保客户端正在与服务器通信。它将向服务器保证执行握手的客户端是进行通信的客户端。它不会向服务器提供任何其他信息——换句话说，服务器不会知道客户端是谁。

在某些情况下，这可能很好 - 例如，如果在会话设置后通过用户名/密码完成登录。

如果您遇到需要通过私钥的加密证明进行客户端身份验证的情况，这还不够好。在这些情况下，您要么需要在客户端签名的地方添加一些更高级别的传输，要么您必须在 SSL 会话设置期间要求客户端身份验证。

这完全取决于应用程序。