我是安全工作的新手，我正在实施别人的设计。该设计要求在没有 DNS（只有 IP）的环境中使用具有 TLS 的 TCP 服务器。
我正在使用典型的证书链（自签名根证书-> 中间证书-> 端点证书）。TCP 服务器将端点证书提供给客户端，该客户端在其代码中固定了中间证书的公共部分。当客户端连接时，它将检查中间证书是否用于签署端点证书。
据我了解，当客户端连接时，会发生密钥交换以确保通信安全，然后客户端使用证书链验证来验证服务器是否真的是它所说的那个人。但是，在这种方案中，冒名顶替者不能在从真实服务器获取证书后直接出示证书吗？
我是否将其误解为缺陷？据我了解，如果没有将证书绑定到的 DNS 名称，检查链（是否使用固定签名的父证书）是不够的。在这里还能做些什么吗？
但是，在这种方案中，冒名顶替者不能在从真实服务器获取证书后直接出示证书吗？
冒名顶替者不能出示和利用真实服务器的证书，除非它也有匹配的私钥。 无论是使用 SAN DNS 条目还是 IP 条目来标识所提供的证书，都是如此。
当攻击者发送服务器的证书时，客户端将使用该证书的公钥加密一个共享密钥（用于生成会话的对称加密密钥）。攻击者将无法恢复秘密，因为他们没有证书的私钥，因此他们将无法完成 TLS 握手。
如需灵感，请查看SSH密钥交换的工作原理：
客户端维护一个“已知服务器”表，将 IP 地址与哈希匹配。当连接到服务器时，客户端接收服务器证书（公钥）并计算它的哈希值，并在“已知服务器”表中查找服务器的 IP 地址。
如果客户端以前见过这个服务器，它可以将计算出的证书哈希值与它为服务器记录的哈希值进行比较。如果它们匹配，那么一切都很好，连接继续。否则，SSH 程序会抛出一个很大的警告信息并拒绝连接。
当客户端第一次连接到服务器时，用户会被告知我们以前没有见过这个服务器，并提出将服务器的证书添加到它的已知服务器表中。可以通过在已知服务器表中手动输入服务器的证书详细信息来绕过此步骤。