应用错误收集

我在X公司工作，我们想与Y公司进行B2B交易。在这样做时，Y要求客户端认证;他们已经提供了服务器端身份验证 - 因此这将是一个相互SSL事务。

我的理解是，我只需要提供我的CA签名证书作为客户端HTTPS通信的一部分。在这样做时，非对称加密保证（即公钥/私钥技术）确保我是我自称的人 - 实际上，我不可能冒充我。（根CA确保我就是我，这就是为什么他们签署我的证书，并且可以证明我没有“制造”证书）。

这是我的问题：我需要提供Y公司吗？

或者，我是否必须提前向他们提供另一个密钥，这样他们才能确保我不是一个碰巧已经“获得”root签名证书的流氓我（公司X）？似乎如果一个人必须向他希望在客户端参与的所有各方提供这个额外的密钥，它似乎会使客户端SSL不像服务器端SSL那样可扩展。我的猜测是，一个人无法“获得”客户端证书;客户端证书的实际传输进一步由某个事务状态编码（不可逆转，可行）。

这是否有意义，我是对的，还是我错了？如果我错了，Y实际上是否需要从连接到它的每一方获得“额外”的预通信密钥？（他们想要验证）？

感谢。

===

感谢下面的回复，至少前两个对目前有帮助（其他人可能会稍后到达）。

让我更详细地谈谈我的技术问题。

假设Y公司试图“重新使用”我的客户端证书，冒充我与另一家公司的另一个客户端交易（比如说“Z”）。这甚至可能吗？我想 - 再次，或许说得不好 - 客户端证书的传输的某些部分会阻止整个密钥被泄露，即在技术上不可能“重复使用”收到客户证书是因为您无法（可行地）对通信客户端证书的通信进行逆向工程。

如果不是这种情况，Y是否可以重新使用证书，在与Z（客户端）通信时冒充X？

ps：我意识到安全永远不是100％，只是试图了解这里技术上可行的和不可行的。

非常感谢！

===

进一步的技术细节，我非常感谢任何额外的输入 - 这非常有用。

从外行人的角度来看，我担心的是当客户发送他的客户证书时，他发送了什么？好吧，他必须使用他的私钥加密该证书。他使用公钥发送密文，然后接收方可以使用该公钥解密私钥编码的有效负载，对吧？这是有道理的，但后来我想知道 - 是什么阻止某人听到这种通信，只是在重放攻击中重复使用私钥编码的有效载荷。只需重播发送的确切零和零。

以下是我认为可以防止这种情况 - 它可以在多个地方的TLS RFC中找到，但是例如在F.1.1中：

F.1.1. Authentication and key exchange

   TLS supports three authentication modes: authentication of both
   parties, server authentication with an unauthenticated client, and
   total anonymity. Whenever the server is authenticated, the channel is
   secure against man-in-the-middle attacks, but completely anonymous
   sessions are inherently vulnerable to such attacks.  Anonymous
   servers cannot authenticate clients. If the server is authenticated,
   its certificate message must provide a valid certificate chain
   leading to an acceptable certificate authority.  Similarly,
   authenticated clients must supply an acceptable certificate to the
   server. Each party is responsible for verifying that the other's
   certificate is valid and has not expired or been revoked.

   The general goal of the key exchange process is to create a
   pre_master_secret known to the communicating parties and not to
   attackers. The pre_master_secret will be used to generate the
   master_secret (see Section 8.1). The master_secret is required to
   generate the certificate verify and finished messages, encryption
   keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
   a correct finished message, parties thus prove that they know the
   correct pre_master_secret.

我认为与会话相关的随机化会阻止这些重播攻击。

听起来是对还是我让事情进一步混乱？

只要您保持私钥安全（并且CA保持其签名密钥安全），“公司Y”不需要任何其他信息来验证您。换句话说，他们可以确定请求确实来自证书中指定的主题。

但是，这并不意味着您授权做任何事情。实际上，大多数使用客户端证书的系统都具有“带外”过程，您可以在其中提供客户端证书中指定的“主题”可分辨名称，并且系统会为该名称分配一些权限。

事实上，由于某些实际限制，某些系统实际上将权限与证书本身相关联（使用颁发者的名称和证书序列号）。这意味着，如果您获得新证书，则可能必须重新注册，即使它具有相同的主题名称。

证书仅保证您拥有某个名称的依赖方。该方需要一些额外的机制来确定您可以做什么。

与基于“秘密”（对称）密钥的身份验证机制（例如，密码）不同，服务器仅需要非对称身份验证的公共信息。私人签名密钥永远不会披露;它当然不是客户端身份验证所必需的。

使用基于密码的对称身份验证，客户端和服务器可以访问相同的字节字符串 - 密钥。使用公钥加密，仅公开密钥对的公钥。从未公开过相应的私钥，也没有发现从公钥中找出私钥的实用方法。

只要您保护私钥安全，Y公司的服务器就无法伪造看似来自您的私钥。

客户端身份验证重放攻击通过要求客户端对包含服务器为每次握手随机生成的数字的消息进行数字签名（这是“ServerHello”消息的“随机”成员）而失败。如果重新使用用于在先前会话中验证客户端的数据包，则服务器将无法验证签名，并且不会验证重播攻击。

RFC 2246, Appendix F.1.1.2可能是一个更有帮助的参考 - 尤其是第三段：

当RSA用于密钥交换时，客户端使用进行身份验证证书验证消息（参见第7.4.8节）。客户签字从master_secret和所有先前握手派生的值消息。这些握手消息包括服务器证书，它将签名绑定到服务器和ServerHello.random，它将签名绑定到当前的握手过程。

客户端SSL理论问题

2 个答案: