客户端 SSL 理论问题

Question

我在 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。身份验证和密钥交换 TLS 支持三种认证方式： 两种认证方式 各方，使用未经身份验证的客户端进行服务器身份验证，以及 完全匿名。每当服务器通过身份验证时，通道就是 防止中间人攻击，但完全匿名 会话本身就容易受到此类攻击。匿名的 服务器无法验证客户端。如果服务器经过身份验证， 其证书消息必须提供有效的证书链 导致可接受的证书颁发机构。相似地， 经过身份验证的客户端必须向客户端提供可接受的证书 服务器。每一方都有责任核实对方的 证书有效且未过期或被吊销。 密钥交换过程的总体目标是创建一个 pre_master_secret 为通信双方所知，而不是 攻击者。 pre_master_secret 将用于生成 master_secret（参见第 8.1 节）。 master_secret 是必需的 生成证书验证和完成消息，加密 密钥和 MAC 机密（参见第 7.4.8、7.4.9 和 6.3 节）。通过发送 正确完成的消息，各方因此证明他们知道 正确的 pre_master_secret。

我相信与会话相关的随机化可以防止这些重放攻击。

听起来是对的还是我进一步混淆了事情？

Answer 1

您的客户端证书（或更准确地说是其私钥）的安全性取决于贵公司的在线和/或物理安全性。

对于极其安全的关系（通常不需要进行太多扩展），服务提供商可能需要在协议中添加一个额外元素以允许他们识别您的站点（而且通常情况下） ，以识别公司内的特定计算机或个人，这是客户证书无法完全做到的。）

这当然会带来一个问题：您的公司将更安全地持有这种额外的身份验证设备有什么保证？ （与客户端证书本身相比）。
对此的标准响应是，这些额外的安全元素通常是非标准的，可能与物理设备、机器 ID 等相关联，因此不太容易可传输（关于这些的专有技术不太常见：黑客知道要查找哪些 RSA 文件，它们长什么样，他们对 KBD-4.hex 文件的起源和使用了解多少？）

额外问题：可以在其他地方使用我的客户端证书吗？
不，他们[通常]不能！此证书的完整性在于您对其私钥的安全保管（是的，证书提供者的类似保管......）。因此，除非他们负责安装上述证书，或者除非他们在您的客户端上的软件（如果有）以某种方式“入侵”到与证书相关的存储/文件/系统 dll，否则他们应该无法重用证书。也就是说，他们不能比任何人更容易重用证书（这在理论上是 NP 困难的），比方说，当客户端与 Y 站点建立会话时，他们会嗅探与身份验证相关的数据包。

额外的问题 ;-)
- 客户证书的性质是什么？
- 中间人问题...

在讨论这些之前，让我们弄清楚一些事情...
这个问题似乎暗示 TLS (Transport Layer Security) 确实是一个很好的协议，但为了理解起见，证书（服务器和客户端）的密钥（公共和私有）可以很好地与替代协议一起使用。此外，TLS 本身提供了几种不同的可能加密算法来支持它（TLS 会话的初始阶段之一是让双方协商他们将有效使用的算法集）。
此外，不言而喻...（如果你说的话也可以）：各个私钥永远不会以任何方式传输，无论是否编码。有时会出现混淆，因为在身份验证阶段之后，各方交换密钥（通常用于对称密码），用于后续交换。此密钥通常是随机生成的，并且与 RSA 密钥（无论是公共密钥还是私有密钥）的性质完全不同！

以简化的方式，客户的证书包含以下信息：
- 证书颁发机构（CA 又名颁发者）
- 证书的“所有者”（又名主题）
- 有效期范围
- 证书的公钥
更详细地说，证书通常位于 X.509 wrapper (? 信封) 中，其中包含附加字段，例如版本号、使用的算法、证书 ID、证书签名（对于确保收到的证书没有被篡改非常重要和）。 X.509 还提供了可选属性，也用于传输其他类型的证书相关数据（如 CRL）

因此证书的内容允许接收者：
- 确保证书本身没有被篡改 - 确保证书的颁发者是接收者接受的颁发者 - 确保证书有效/最新且未被撤销 - 了解公钥及其底层大小和算法

关于中间人问题，特别是“重播”之前会话中可能记录的数据包交换的可能性。

协议为此目的使用变量，可能是随机的 MAC（消息验证码）。本质上，在谈判阶段，一方（不确定哪一方，可能会有所不同……）产生一个随机字符串并将其发送给另一方。然后，这个随机值按原样（或者通常通过双方都知道的算法进行一些额外处理）用作发送的消息的一部分。它是用发送方的私钥编码的，如果接收方可以解码它（使用发送方的公钥）并识别（再次变量）MAC，则证明发送方拥有私钥证书，因此它的身份被断言。因为 MAC 每次都不同，所以预先录制的会话没有帮助（为了这个简单的目的）。

Answer 2

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

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

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

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

---

与基于“秘密”（对称）密钥（例如密码）的身份验证机制不同，服务器只需要公开信息来进行非对称身份验证。私人签名密钥永远不应该被披露；客户端身份验证当然不需要。

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

只要您妥善保管私钥，Y 公司的服务器就无法伪造看似来自您的请求。

---

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

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

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