当客户向您提供他们的公共证书时进行相互身份验证

Question

通常，2 路 ssl 又名相互身份验证包括生成服务器 ca 密钥和证书等。然后客户端生成一个 CSR，将其提供给您，您签署他们的 CSR 并向他们提供客户端证书。

然而，

我遇到过一种情况，客户要求我通过交换彼此的 x509 公共证书来实现“相互身份验证”。这个听说过吗？也许称为“2 路 SSL”或“相互身份验证”以外的名称。

我正在努力寻找与 openssl 有关的任何文档或信息。

Answer 1

我遇到过一种情况，客户要求我通过交换彼此的 x509 公共证书来实现“相互身份验证”。这个听说过吗？

我相信它仍然被称为相互认证。

通常，基于证书的相互身份验证属于两种模型之一。第一种是具有 CA 层次结构的企业模型，组织的 CA 签署客户端和服务器证书。

第二种模型是客户端在所谓的原始绑定证书中使用自签名证书。它被称为起源绑定，因为每个需要证书的站点（起源）都会让客户端提供一个。起源绑定证书是 IETF令牌绑定协议的基础。

我不清楚令牌绑定是否具有与原始绑定证书相同的安全属性。您会看到，我们可以通过将身份验证作为通道设置的一部分，使用原始绑定证书来阻止中间人攻击。令牌绑定解耦了绑定并将其在堆栈中向上移动。我相信它允许中间人充当中间人。

企业证书

在企业模型中，您可以使用 OpenSSL 执行以下操作。

在服务器上执行以下操作。服务器将处理客户端证书验证：

SSL_CTX_set_verify使用SSL_VERIFY_PEER和进行呼叫SSL_VERIFY_FAIL_IF_NO_PEER_CERT。
调用CTX_set_client_CA_list以设置服务器将接受的颁发者 CA 列表。这会导致将适当的 SSL/TLS 消息发送到客户端，提示输入证书。这仅向客户端发送名称列表；他们仍然必须在服务器上受到信任
SSL_CTX_load_verify_locations与服务器接受的发行人通话。这增加了服务器端的信任。

在客户端执行以下操作：

原产地绑定证书

原始绑定证书和自签名证书略有不同，因为没有 CA 层次结构。

在服务器上执行以下操作。服务器不会调用SSL_CTX_load_verify_locations或CTX_set_client_CA_list因为它是自签名证书。

在客户端执行以下操作。与企业模式相同。

缺少企业 CA 意味着客户端的自签名证书需要带外传送到服务器。然后，服务器需要保留某种目录，用于根据可分辨名称和序列号查找客户端证书。您真正关心的是客户端的公钥。在本例中，X509 证书是演示详细信息。它只是打包，因为它通常通过权威机构的签名将身份绑定到公钥（但不是在这个模型中）。

此模型中的攻击（房间中的 500 磅大猩猩）是坏人通过使用相同的专有名称和序列号冒充用户，因为没有注册机构 (RA)。您需要采取一些措施来确保您不被欺骗，例如向用户发送电子邮件以确认他们的公钥更改是预期的。

该攻击意味着当您注册用户时，您需要三到四件事：

更糟糕的是，用户可能拥有 3 或 4 台设备，因此他们为每台设备创建一个新的原始绑定证书。您还需要妥善处理该注册。

总而言之，真正重要的是电子邮件地址以及与电子邮件地址关联的不同公钥/身份。这些身份存储在具有唯一的{专有名称，序列号}对的 X509 证书中。您可能希望它们是唯一的以用于审核目的，但设备之间可能会进行一些复制/粘贴。

我正在努力寻找与 openssl 有关的任何文档或信息。

您可能在查找信息时遇到困难，因为这是一个更高级别的安全架构和设计问题。为了帮助获得一些参考，请首先阅读 Dietz、Czeskis、Balfanz 和 Wallach 的Origin-Bound Certificates: A Fresh Approach to Strong Client Authentication for the Web。还可以访问 Peter Gutmann 的工程安全和 Ross Anderson 的安全工程。

原始绑定证书可用于取代几乎所有基于密码的身份验证系统。它适用于几乎所有系统，从基于用户名/密码的身份验证到 Web 服务中使用的 API 密钥。密码仍然用于保护本地私钥，但密码不会放在网络上。

当数据敏感级别需要更强的安全控制时，客户端证书是我们首先采取的措施之一，以阻止密码处理不当以及身份验证和授权控制的失败。不要相信苹果、微软、谷歌（等）对密码的使用和处理。多年来它一直存在缺陷。这只是公司让用户变得容易，以便他们能够获得业务。