ICANN 博文

敬请阅读 ICANN 的博文,了解最新政策制定活动和区域事务等等。

信任互联网标识符的不同方式

2017 年 04 月 3 日

本部分内容不仅提供联合国六种官方语言版本,还提供以下语言版本

近期新闻称,Google 的 Chrome 浏览器拟将 Symantec 颁发的安全传输层协议 (TLS) 证书的信任等级调至低于其他认证机构 (CA) 的证书,这一举措再次引发如何向互联网用户传递信任的辩论。TLS 证书用于保证对网站安全性的信任,但 Web 公钥基础架构 (PKI) 面对的一个情况是,行业中存在超过 100 家 CA,其中任一家都可以颁发证书来验证网站。这带来了一个挑战:为了确保他们所颁发的证书值得信任,必须制定一套规则,以便管理所有这些 CA,以及剔除不符合规则要求的 CA。

在过去二十年间,Mozilla (Firefox)、Google (Chrome)、Apple (Safari) 和 Microsoft(Internet Explorer 和 Edge)等浏览器厂商不得不扮演 CA 可信度仲裁者的角色。根据浏览器厂商想要保护其用户的方式,每个浏览器都制定了相关政策,以处理那些看起来不符合可信度要求的 CA。CA/浏览器论坛的成员包括各大浏览器厂商和几十个 CA。这个群体制定了一套“基线要求”,其中描述了 CA 应遵循的政策,但该群体不负责对其成员进行监督。因此,浏览器厂商需要执行自己的 CA 可信度标准。因此,他们可能会采取一些强制措施,如 Google 限制 Symantec 颁发的证书;在过去,他们还曾限制过 WoSign 颁发的证书Diginotar 颁发的证书等。

DNSSEC 是否能解决这个问题?

在这些辩论中,人们通常会提出通过域名系统安全扩展 (DNSSEC) 来保护域名系统 (DNS),将其作为目前基于 X.509 的 Web PKI 的潜在替代或辅助手段。从全局角度看,Web PKI 旨在保护网页内容的完整性,而 DNSSEC 旨在保护可引导您访问这些网页的 DNS 数据的完整性。但是,这两个系统采用完全不同的模型来信任其数据。两个系统之间的主要区别之一在于,Web PKI 依赖于需要全部给予完全信任的上百个组织,而 DNSSEC 具有单一的全局信任锚。另一个显著区别是,Web PKI 中的验证是由用户选择的浏览器完成,而 DNSSEC 的验证由用户的计算机选择使用的解析器完成。

单一的全局信任锚可为 DNSSEC 提供优势。相比在 Web PKI 中,互联网社群要求 DNS 中的信任机制更加透明度。为响应此呼声,ICANN 已建立一个高度开放、透明和负责的流程。受托社群代表参与了该流程的仪式(人们可通过现场直播或录播观看),在维护加密密钥方面发挥了积极作用。技术社群为打造 DNSSEC 信任链的管理流程提供了帮助,并对 ICANN 用来更新(或轮转)根区密钥签名密钥(称为 KSK 轮转)的流程作出了重大贡献。

Web PKI 不会很快被弃用,但浏览器与 CA 交互的方式很可能会稳步发展。事实上,目前人们正在实施一些基于 DNSSEC 的措施,通过基于 DNS 的名称实体验证 (DANE) 来实现 Web PKI 与 DNSSEC 之间更好的交互。互联网工程任务组 (IETF) 中的 TLS 工作组正致力于让 TLS 客户端能在不必进行其他 DNS 记录查询的前提下,对 TLS 服务器证书执行 DANE 验证。这项工作一旦完成,便可能会带来一个很有意思的浏览器混合信任模型,它将能充分利用 DNSSEC 信任模型的各种优势功能。

CA 将逐步发展

考虑到 Web PKI 的规模及其核心部分鲜为人知的参与者的数量,互联网用户很可能继续就如何确保 DNS 中的信任提出疑问。浏览器厂商将采取更多措施来增强用户安全性。随着 DNSSEC 得到越来越广泛的部署,使用 DNSSEC 来保护 DNS 将更有助于建立信任,因为它让互联网用户能够安全地进行通信。