Authentication 客户端SSL理论问题

我在X公司工作，我们希望与Y公司进行B2B交易。在这样做时，Y需要客户端身份验证；它们已经提供了服务器端身份验证——因此这将是一个相互的SSL事务

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

我的问题是：这就是我为Y公司提供的一切吗

或者，我是否必须提前向他们提供另一个密钥，以便他们能够确保我不是碰巧为我“持有”根签名证书的流氓（X公司）？看起来，如果一个人必须向他希望在客户端与之接触的所有各方提供这个额外的密钥，那么客户端SSL的可伸缩性似乎不如服务器端SSL。我的猜测是，一个人不可能“持有”客户端证书；客户端证书的实际传输由事务的某些状态进一步编码（这是不可行的反向工程）

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

谢谢

===

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

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

假设Y公司试图“重复使用”我的客户端证书，在与另一家公司的另一个客户端交易中冒充我（比如“Z”）。这可能吗？我在想，客户端证书传输的某些部分可能会阻止整个密钥被泄露，也就是说，在技术上不可能“重用”收到的客户端证书，因为您不能（切实可行）对与客户证书进行通信的通信进行反向工程

如果不是这样，Y是否可以重新使用证书，在（客户端）与Z通信时模拟X

ps：我意识到安全性从来不是100%，只是试图理解什么在技术上可行，什么不可行

非常感谢

===

进一步的技术细节，我非常感谢任何额外的投入-这是非常有益的

从外行的角度来看，我关心的是，当客户发送他的客户证书时，他发送的是什么？他必须用他的私钥加密证书。他用公钥发送密文，然后接收方可以使用该公钥解密私钥编码的有效载荷，对吗？这是有道理的，但我想知道——是什么阻止人们听到这种通信，并在重播攻击中简单地重复使用私钥编码的有效载荷。只需重播发送的精确的1和0

以下是我认为可以防止这种情况的原因——它可以在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. F.1.1。身份验证和密钥交换 TLS支持三种身份验证模式：两者的身份验证 参与方，使用未经身份验证的客户端进行服务器身份验证，以及 完全匿名。每当服务器通过身份验证时，通道将被激活 防止中间人攻击，但完全匿名 会话天生容易受到此类攻击。匿名的 服务器无法对客户端进行身份验证。如果服务器经过身份验证， 其证书消息必须提供有效的证书链 导致可接受的证书颁发机构。同样地， 经过身份验证的客户端必须向 服务器。每一方负责验证另一方的 证书有效且未过期或被吊销。 密钥交换过程的总体目标是创建一个 通信方已知的且不为通信方所知的pre_master_秘密 袭击者。pre_master_secret将用于生成 掌握秘密（见第8.1节）。主密钥必须是 生成证书验证和完成消息、加密 密钥和MAC机密（见第7.4.8、7.4.9和6.3节）。发送 一个正确完成的消息，各方证明他们知道 正确的密码。 我相信是与会话相关的随机化阻止了这些重播攻击

---

听起来不错，还是我把事情弄糊涂了？

您的客户端证书（或者更准确地说是它的私钥）的安全性仅与您公司的在线和/或物理安全性相同

对于极为安全的关系（通常不需要太多的扩展），服务提供商可能需要协议中的额外元素来识别您的站点（通常情况下，识别公司内的特定计算机或个人，这是客户证书不能完全做到的。）

这当然带来了一个问题：如何保证您的公司能够更安全地持有此额外的身份验证设备？（与客户端站点证书本身相比）.
对此的标准响应是，这些额外的安全元素位通常是非标准的，可能与物理设备、机器ID等相关，因此不易传输（关于这些的诀窍并不常见：黑客知道要查找什么样的RSA文件，它们看起来像什么，他们对KBD-4.hex文件的起源和用法知道多少？）

额外问题：C