![采用](https://linux22.com/image/718515/%E9%87%87%E7%94%A8.png)
我只是想知道。我们使用了很多 SSL 证书。如今,我们几乎只使用 letsencrypt(谢谢!)。这些证书的底线是,证书上域名所有权的证明来自操纵 DNS 记录或这些域下的网站的能力。DNS 证明来自将一些密钥(由 letsencrypt 提供)作为 TXT 记录添加到 DNS。
因此,如果有足够的证据能够更改域的 DNS 记录,为什么不使用带有 DNS 中指纹的自签名证书呢?
我想说这给出了与基于 DNS 的 letsencrypt(和其他 CA)的程序完全相同的信任程度:
- 创建自签名 CA(只需按照各种操作方法的步骤操作即可)
- 为某些域名创建证书
- 使用步骤 1 中的 CA 签署步骤 2 中的证书。您现在拥有由非受信任 CA 签署的基本证书
- 在每个域的 DNS 中添加一个 TXT(或专用)记录,说明:我们使用此 CA 签署了此域的证书。例如:“CA=-fingerpint of CA-”
- 浏览器下载证书并通过将 CA / CA 证书的指纹与给定域的 DNS 中的数据进行比较来验证它。
这样就可以创建不受第三方干扰的受信任自签名证书,其信任级别与任何基本 SSL 证书相同。只要您可以访问 DNS,您的证书就是有效的。甚至可以添加一些类似 DNSSEC 的加密,对 CA 和 SOA 记录进行哈希处理,以确保在 DNS 记录发生变化时信任消失。
以前考虑过这个问题吗?
耶尔默
答案1
实现这一目标的基本基础设施是存在的,称为基于 DNS 的命名实体身份验证 (DANE),并在RFC6698。它通过TLSA
资源记录工作,该资源记录指定链中最终实体或其中一个 CA 的证书或其公钥(实际上有四种不同类型,有关详细信息,请参阅 RFC)。
采用
然而,DANE 尚未得到广泛采用。VeriSign 监控DNSSEC 和 DANE 采用和跟踪其随时间的增长:
相比之下,根据 VeriSign 的说法,存在大约 270 万个 DNS 区域,这意味着所有区域中略多于 1% 的区域至少有一个 TLSA 记录。
我无法给出任何权威的答案,为什么是 DANE,但我的猜测如下:
DANE 面临与证书撤销列表 (CRL) 和在线证书状态协议 (OCSP) 相同的问题。为了验证所提供证书的有效性,必须联系第三方。Hanno Böck给出了很好的概述,为什么这在实践中是一个大问题。归根结底,当你无法联系到第三方时该怎么办。浏览器供应商选择软失败在这种情况下(又名允许),这使得整个事情变得毫无意义,Chrome 最终决定在 2012 年禁用 OCSP。
DNSSEC
可以说,DNS 提供的可用性比 CA 的 CRL 和 OCSP 服务器要好得多,但它仍然无法进行离线验证。此外,DANE 应仅与 DNSSEC 结合使用。由于普通 DNS 通过未经身份验证的 UDP 运行,因此很容易受到伪造、MITM 攻击等。采用 DNSSEC 比采用 DANE 要好得多,但还远未普及。
而使用 DNSSEC 我们又一次遇到了软故障问题。据我所知,没有哪个主流服务器/客户端操作系统默认提供验证 DNSSEC 解析器。
然后还有撤销的问题。DNSSEC 没有撤销机制,而是依赖于短期密钥。
软件支持
所有参与的软件都必须实现 DANE 支持。
理论上,您可能会认为,这将是加密库的工作,应用程序开发人员不需要做太多工作,但事实是,加密库通常只提供原语,应用程序必须自己进行大量配置和设置(不幸的是,有很多方法可以出错)。
我不知道是否有任何主要的 Web 服务器(例如 Apache 或 nginx)实现了 DANE 或计划这样做。Web 服务器在这里特别重要,因为越来越多的东西是基于 Web 技术构建的,因此它们通常是第一个实现东西的地方。
当我们将 CRL、OCSP 和 OCSP Stapling 进行比较时,我们可能能够推断出 DANE 的采用情况。只有使用 OpenSSL、libnss、GnuTLS 等的一些应用程序支持这些功能。Apache 或 nginx 等主要软件花了一段时间才支持它,再次回顾 Hanno Böck 的文章,他们做错了,他们的实现存在缺陷。其他主要软件项目,如 Postfix 或 Dovecot不支持 OCSP并且 CRL 功能非常有限,基本上指向文件系统中的文件(不一定定期重新读取,因此您必须手动重新加载服务器等)。请记住,这些是经常使用 TLS 的项目。然后您可以开始研究 TLS 不太常见的事物,例如 PostgreSQL/MySQL,也许它们最多提供 CRL。
因此,我甚至还没有让现代网络服务器实现它,而且大多数其他软件甚至还没有实现 OCSP 和 CRL,祝您 5 年的企业应用程序或设备好运。
潜在应用
那么你实际上可以在哪里使用 DANE?截至目前,还不能在一般互联网上使用。如果你控制服务器和客户端,也许这是一个选择,但在这种情况下,你通常可以求助于公钥固定。
在邮件领域,DANE 正在获得一些关注,因为 SMTP 长期以来没有任何类型的经过身份验证的传输加密。SMTP 服务器有时会在彼此之间使用 TLS,但并未验证证书中的名称是否真正匹配,他们现在开始通过 DANE 进行检查。
答案2
不同类型的证书验证程序
对于常规 CA 签名证书,证书验证有以下几个级别:
- 域名验证 (DV)
仅验证域名所有权,证书中仅显示域名为“主题” - 组织验证 (OV)
域名和所有者名称经过验证,域名和所有者名称在证书中显示为“主题” - 扩展验证 (EV)
对所有者实体进行更严格的验证,域名和所有者名称在证书中显示为“主题”,绿色条带有所有者名称
您描述并建议替代的过程仅适用于最低级别,即域验证(DV)。
DV 是验证相对容易自动化的级别,例如 LetsEncrypt 所做的那样,并且提供与 DNS 所能提供的类似的信任级别,如果它被用作信任锚的唯一来源(UI 含义,证书可能是受信任的,但包含绝对未经验证的额外数据)。
基于 DNS 的命名实体身份验证 (DANE)
丹麦建立在 DNSSEC 之上(因为 DNS 数据真实性至关重要)以在 DNS 中发布针对 TLS 客户端的信任锚信息。
它使用TLSA
RR 类型,可用于识别证书或公钥(选择器) 无论是终端实体还是 CA,都可能需要或不需要常规证书链验证才能成功 (证书使用)以及证书/密钥数据在记录中的表示方式(匹配类型)。
记录TLSA
所有者名称具有表示端口和协议的前缀(例如_443._tcp
),并且 RData除了要匹配的证书/密钥数据外还表示cert usage
、selector
和模式。请参阅matching type
RFC6698 第 2.1 节了解这些参数的具体信息。
TLSA
例如,记录可以如下所示:
_443._tcp.www.example.com. IN TLSA 2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971
在使用模式2
或3
(表示仅使用 TLSA 信任锚)的情况下,支持 DANE 的客户端将接受未由普遍信任的 CA 签名但与记录匹配的证书TLSA
。
这在概念上与您在问题中提出的内容相同。
问题是什么?DANE 感知客户端目前或多或少不存在,其中一个问题是 DNSSEC 本身的部署范围并不广泛(尤其是在客户端机器上的验证),而 DANE 可能需要这些部署才能成功。考虑到 DANE 是首批依赖经过身份验证的 DNS 数据的潜在大型新用例之一,这可能有点像先有鸡还是先有蛋的问题。
有一个添加 DNSSEC 和 DANE 验证的浏览器插件,除此之外,目前还没有太多接近主流的东西。而且,作为插件而不是原生支持,它在一般用途上更像是一个概念验证。
这是可以做到的。我们一直在考虑。这仍有可能发生,但目前还没有太多进展。