在配置了客户端身份验证的 TLS 握手中，有一个步骤是服务器接收客户端的证书并选择是否信任它（例如，在 Java 中，它是通过 TrustManager 完成的）。
我想知道来自服务器的最终“信任失败”消息是在服务器确保客户端真正拥有该公钥之前还是之后发送的（例如，通过首先从握手中接收一些用客户端的私有密钥编码的消息钥匙）。
我的问题的目的是查看第三方是否有可能通过假装是该客户端并使用他的公钥来检查服务器是否信任客户端。
注意：在具有特定安全要求的上下文中使用 TLS 时，风险是真实存在的。例如，假设一个 P2P 应用程序在对等点之间使用 TLS，并使用 TrustManager 作为从其联系人列表中对对等点进行身份验证的一种方式。此联系人列表应该是私人的。ISP 可以列出节点与之通信的 IP，然后通过与它开始 TLS 握手来获取他的公共证书，然后他可以尝试连接 IP 列表中的每个其他节点。最后，ISP 可以获得很大一部分本应是私有的联系人列表。
这取决于实施。我们的实现会立即发送错误，就像其他实现一样——我想大多数都是这样做的。
但是没关系：如果证书无效，服务器会发送特定的错误代码（BadCertificate），因此无论何时发送此代码，攻击者都会知道证书未被接受。保护服务器免受这种攻击将需要服务器发送不同的错误代码，这会混淆合法客户端。
检测到证书是否被服务器接受的风险（或不愉快的后果）是值得怀疑的。如果这对您很重要，您可以更改错误代码并构建您使用的 OpenSSL 或其他 SSL 服务器模块的自定义版本。
OpenSSL 也会在客户端证书消息中收到客户端证书后立即对其进行验证。
但正如 Eugene 所说，如果服务器发送有意义的警报，那么您是立即发送bad_certificate还是仅在验证证书验证消息中的签名之后发送都没有关系。这只会阻止某人在他们另外发送格式错误的签名（例如通过使用错误的密钥）时发现证书是否可信。但是，如果服务器是以这种方式实现的，您所要做的就是使用您刚刚生成的私钥签署您的证书验证消息。然后签名将有效，然后服务器将尽职地验证您发送的证书，显示与以前相同的信息。
为了缓解这种情况，您实际上必须使用根本不发送相应警报的定制服务器，而是发送一些不那么暴露的东西。