多个 CA 签署一个 Cert/CSR?

信息安全 密码学 验证 证书 公钥基础设施 证书颁发机构
2021-08-09 21:21:09

刚刚在Slashdot上看到了这个建议

因此,我看到很多人想要切换到自签名证书(IMO 大多不了解确保安全实际涉及的内容),以及从不同网络路径检查证书的想法(如果您唯一的路径受到损害,您如何保护与为您进行检查的服务的通信?)。

所以这里有一个替代的想法:需要多个 CA。

与其采用“扩展验证”方式,这种方式对于同一提供商提供的更多服务来说更划算,不如在一个证书上拥有多个 CA 签名。

在同一时间范围内破坏多个 CA 以创建证书比创建证书要困难得多。更重要的是,它会使撤销大型 CA 变得更加容易。

假设新规范是让一个站点的证书由 5 个不同的 CA 签名,并且可接受的最小数量是 3 个签名。

然后,如果 Verisign 受到威胁,那么提取他们的证书就没有问题:您的证书上只有 4 个有效签名,这仍然没问题。这应该会给 CA 带来更大的压力,以使其表现更好。

即使是 Verisign 也无法相信他们的安全问题会因为它们的受欢迎程度而得到解决,因为即使是最大的 CA 也完全可以消耗掉,而最终用户不需要太多关心。该站点只需使用不同的 5th CA 即可恢复全部实力。

听起来这会起作用(尽管您会获得安全等级,而不是二进制证书验证/不验证)。生存能力怎么样?可以在现有标准内完成吗?我无法理解是否会向多个 CA 颁发相同的 CSR,然后向浏览器提供一大堆证书……如果您只有一个证书由多个 CA 依次签名。

4个回答

关于 SSL/TLS的更改:SSL/TLS协议以匿名 blob 的形式发送证书,可以有任何大小,最大约为 16 MB(这很可笑)。如果要使用一些新的证书格式,则不需要更改协议本身。

SSL/TLS 实现期望 blob 被编码为X.509 证书这样的证书可以容纳单个颁发者(其中写有 CA 名称)和单个签名。因此,您不能在现有 X.509 标准的范围内拥有“多重签名证书”。可以获得多个证书,每个证书都具有相同的公钥,然后您只需要某种约定,以便 SSL 客户端软件不介意为服务器接收多个证书,并检查所有证书。

关于颁发证书:证书请求只是请求者公钥、他的预期名称以及 CA 可以在颁发的证书中自由复制或不复制的任何类型的信息的容器。拥有多个证书没有理论上的问题,即使来自不同的 CA,它们都包含您的姓名和公钥;实际上,任何CA 都可以颁发这样的证书,而无需与您进行任何交互。他们都可以使用相同的证书请求。在实践中,这将需要一些更改,因为现有 CA 颁发证书作为基于 Web 的场景的一部分,其中指示买方的浏览器生成新的密钥对,并将公共部分发送给 CA,而无需与人工买方进行任何交互。由于让每台服务器拥有至少 3 个证书的想法基本上是服务器证书市场的三倍,我很确定商业 CA 愿意对其平台进行相关调整。

关于这个想法的合理性:请求多重验证是一个合理的想法(OpenPGP格式已经做到了,主要是为了处理信任网络 CA 的固有不可靠性)但它可能适得其反:如果有一个流氓或妥协CA 不会影响一般安全性,下一个类似 Comodo 的活动可能会受到较少的宣传,可能根本没有。多重验证倾向于鼓励普遍的宽大处理和责任的丧失。

On Convergence: slashdot 引用所谈论的是Convergence这是一个试图站稳脚跟的新系统。有关协议的一些详细信息和指针,请参阅此答案

我实际上认为这将是一个非常好的主意。但它需要新版本的 SSL 和 TLS 来支持。目前,一切都是在假设只有一个信任锚的情况下设计的。这意味着它可能永远不会发生。我仍然与声称我们“需要”支持 Windows 98 的人争论不休。

我怀疑这个想法是否可行。CA 之间需要一个 API 来自动化证书签名。他们会检查什么?如果他们不检查彼此的请求,那么获得一个 CA API 访问权限的黑客(例如在 Comodo 和 DigiNotar 案例中)仍然会获胜。如果他们确实检查 CA 间签名请求,要检查什么?

多 CA 方法可以防止攻击者获取 *.google.com 等知名域的证书,如果第二个签名 CA 会标记第一个失败的证书。

不过,就我个人而言,我喜欢 moxie 的网络视角方法。特别是因为它将信任决定交还给用户,而不是使其成为仅限技术人员的解决方案。

一种更好的方法已经在以 DNSSEC 和 DANE 的形式进行。当前站点证书系统的主要漏洞是任何 CA 都可以为任何域名颁发证书。因此,只需要一个错误的 CA 就可以破坏任何域。相反,可以指定为某个域签署站点证书的密钥:

来自https://www.rfc-editor.org/rfc/rfc6698(DANE 规范):

“TLS 所依赖的公共 CA 模型从根本上易受攻击,因为它允许这些 CA 中的任何一个为任何域名颁发证书。一个受信任的 CA 背叛了它的信任,无论是自愿还是通过提供不够有力的保护它的秘密和功能, 可能会破坏任何与 TLS 一起使用的证书所提供的安全性。出现此问题是因为受损的 CA 可以颁发包含假密钥的替换证书。最近与 CA 或其受信任的合作伙伴受损的经验导致非常严重安全问题,例如多个国家的政府试图窃听和/或破坏数百万用户信任的主要受 TLS 保护的网站。”