一个中间人攻击时，攻击者插入自己的客户端和服务器，并假冒之间谈话的服务器时，客户交谈时客户端的，而假冒的服务器。“模拟”是有道理的，只是因为有是预期的对等节点标识; 您不能冒充匿名客户。

从服务器的角度来看，如果客户端显示证书并将其私钥用作 CertificateVerify 消息的一部分（如SSL/TLS 标准第 7.4.8 节所述），则服务器使用对于一组不包括敌对或不称职的根 CA 的信任锚，则服务器可以保证它正在与正确的客户端（由客户端证书标识的客户端）进行通信。该保证适用于连接中的所有后续数据（它不会扩展到客户端显示证书的握手之前交换的数据，以防握手是“重新协商”）。

这意味着客户端证书确实可以防止恶意 CA 注入客户端信任库的特定情况。在那种情况下，“攻击者”成功地让客户端信任了一个特定的受攻击者控制的根 CA，从而允许攻击者通过为目标服务器动态创建假证书来运行中间人攻击（这正是某些组织中部署的一些“SSL 内容过滤”代理会发生什么情况）。这样的 MitM 会破坏客户端证书身份验证，因为客户端作为 CertificateVerify 消息的一部分签名的是对大量数据（包括服务器证书）计算的哈希值——在 MitM 场景中，客户端看不到“正确”的证书，并且因此计算出错误的签名，服务器检测到该签名。

从客户端的角度来看，如果服务器请求了客户端证书并由客户端显示，则客户端知道真正的服务器将检测到任何 MitM。客户端不会检测到中间人本身；如果有正在进行的中间人攻击，那么客户端真的是在和攻击者交谈，攻击者不会告诉客户端“顺便说一句，你目前正在被攻击”。

从这个意义上说，客户端证书可以防止真正的中间人（又称“双面模拟”），但不能防止更简单的欺诈（单面模拟，即假服务器）。

底线：在存在具有相互客户端-服务器身份验证的 SSL 的情况下（都向对方发送证书），成功的中间人需要攻击者在客户端和服务器中植入恶意 CA。但是，如果攻击者只能在客户端中植入恶意 CA，那么客户端仍然处于相当糟糕的境地（即使完整的中间人被阻止）。

与任何安全的公私密钥技术一样，客户端证书将提供针对 MITM 的保护。

客户端证书在这方面的主要问题是网络钓鱼或攻击者以其他方式从最终用户检索证书/私钥，这通常比从服务器更容易，因为最终用户对安全性知之甚少。当攻击者检索到 pk/certificate 时，他可以通过中继来自客户端的所有信息来执行 MITM 攻击，因为他可以使用 pk/certificate 重新加密数据。

请注意，对于完全成功的 MITM 攻击，需要客户端和服务器的 pk/证书，否则无法解密通信的一部分。

如果你坚持一个中间人（不涉及证书存储的操作），那么答案是所提供的严格定义TLS RFC，附录F.1.1：“每当服务器进行身份验证，该通道是针对人为安全中间攻击”。因此，对于纯粹的 MiTM，甚至不需要客户端证书。