问题描述
在配置了客户端身份验证的TLS握手中，有一个步骤，服务器将接收客户端的证书并选择是否信任该证书(例如，在Java中，它是通过TrustManager完成的.)
In a TLS handshake configured with a client authentication, there is a step where the server receives the client's certificate and choose to trust it or not (for instance, in Java it is done via a TrustManager).
我想知道从服务器发出的最终信任失败"消息是在服务器确保客户端真正拥有该公钥之前或之后发送的(例如，通过首先从握手编码为的消息中接收一些消息)客户的私钥).
I would like to know if the eventual "trust failure" message from the server is sent before or after the server made sure that the client really own that public key (for example, by receiving first some messages from the handshake encoded with the client's private key).
我的问题的目的是通过伪装成该客户端并使用其公共密钥来查看第三方是否有可能检查服务器是否信任客户端.
The purpose of my question is to see if it is possible for a third party to check if the server trust a client, by pretending to be this client and by using his public key.
注意:当在具有特定安全要求的上下文中使用TLS时，风险确实存在.例如，假设一个P2P应用程序在对等方之间使用TLS，并使用TrustManager作为从其联系人列表中对等方进行身份验证的方法.该联系人列表应该是私人的. ISP可以列出与节点通信的IP，然后通过与其进行TLS握手来获取其公共证书，然后可以尝试将每个其他节点连接到IP列表上.最终，ISP可以在联系人列表中获得很大一部分，而该列表应该是私有的.
Note: The risk is real when TLS is used in a context with specific security requirements. For instance, let's suppose a P2P application which uses TLS between peers, and which use the TrustManager as a way to authenticate peers from his contact list. This contact list is supposed to be private. An ISP can list the IPs with who a node communicates, then get his public certificate by starting a TLS handshake with it, then he can try to connect each another nodes on the IP list. In the end, the ISP can get a big part of the contact list which was supposed to be private.
推荐答案
OpenSSL也在客户端证书消息中收到客户端证书后立即验证客户端证书.
OpenSSL verifies the client certificate, too, immediately upon receiving it in the Client Certificate message.
但是正如Eugene所说，如果服务器发送有意义的警报，则立即发送或仅在已验证证书验证"消息中的签名之后发送bad_certificate无关紧要.这只会阻止某人另外发送格式错误的签名(例如，使用错误的密钥)来确定证书是否受信任.但是，如果以这种方式实施服务器，那么您要做的就是使用刚刚生成的私钥对证书验证"消息进行签名.然后签名将是有效的，然后服务器将忠实地验证您发送的证书，并显示与以前相同的信息.
But it is as Eugene says, if the server sends meaningful alerts, then it does not matter if you send bad_certificate right away or only after having verified the signature in the Certificate Verify message. This would only prevent someone from finding out whether a certificate is trusted or not if they additionally send a malformed signature (e.g. by using the wrong key). But if a server were implemented that way, all you had to do is sign your Certificate Verify message with a private key you just generated. Then the signature will be valid and the server will then dutifully validate the certificate you sent, revealing the same information as before.
要减轻这种情况，您实际上必须使用自定义服务器，该服务器根本不会发送相应的警报，而只会发送一些不易透露的信息.
To mitigate this situation you would really have to use a customized server that does not send the corresponding alert at all, but rather something less revealing.
这篇关于安全与安保客户端身份验证时的TLS握手的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！