证书透明度如何重塑互联网信任

我们构建的互联网安全体系其基础是我们无法真正验证的信任。

证书颁发机构是互联网安全的守门人，但历史表明，即使是最受信任的 CA 机构也可能变得不可靠。本文探讨了引入了证书透明度（Certificate Transparency，简称 CT）的原因，它的工作原理，以及它对数字信任的未来意味着什么。我们将揭示现实世界的违规行为，深入了解 CT 的架构（日志、监控器和审计器），并探讨它如何重塑了 TLS 生态系统。

为什么我们不再信任安全锁

几十年来，浏览器地址栏中的绿色安全锁一直是事实上的在线安全信号。但在后台，那个熟悉的图标依赖于一个脆弱的证书颁发机构网络，这些私人公司受托验证网站的身份并颁发数字证书。

遗憾的是，事实证明，这种模式非常容易被滥用。

从国家干预到草率的操作规范，证书生态系统经历了多次信任危机。问题不在于加密本身——而在于谁来验证所有权和身份我们才信任。

事实证明，绿色安全锁可能被伪造。

这就是引入 CT 的原因——一个仅支持追加的、公开可审计的日志，其中记录了所有已颁发的证书。通过实现信任的可验证性与透明度，CT 为 TLS 协议提供了有力补充。

在本文中，我们将深入剖析 CT 的工作原理和重要性，以及基础设施工程师和安全架构师在当今愈加透明的 Web 环境中构建和运营服务时应该掌握的知识。

理解问题：当 CA 变得不可靠时

想象一下，你正在运行一个安全的 Web 应用程序（正确配置了 TLS 证书）。一切看起来都很好……直到你意识到，在你不知情的情况下，一家遭到入侵的 CA 机构为你的域名颁发了一个恶意证书。

这并非假设。以下是臭名昭著的CA故障简史：

DigiNotar（2011 年）

黑客入侵了这家位于荷兰的 CA 机构，并颁发了 500 多个欺诈性证书，其中有一个是针对谷歌的。荷兰政府撤销了对 DigiNotar 的信任，但在此之前已经发生了广泛的中间人（MITM）攻击。

赛门铁克（2015-2017 年）

这家机构被发现为真实域名（如“google.com”）颁发了测试证书。最终，所有赛门铁克根证书都不再被 Chrome 和 Firefox 所信任。

Trustwave、CNNIC 等

每家机构都被发现签发了可疑或未经授权的证书，通常以内部测试或国家利益为由。

这些事件揭示了 CA 模型的一个核心缺陷：它是一个多对多的信任系统，其中任何一个故障点（任何 CA）都可能破坏任何一个网站。浏览器平等地信任所有根 CA。

为什么这种情况会持续存在？在 CT 出现之前，关于颁发了哪些证书，没有一个公开的记录。除非网站所有者通过缓慢且很少使用的撤销检查来发现欺诈性证书，否则滥用行为可能长期存在而不被察觉。

证书透明度的工作原理

证书透明度引入了一个仅支持追加的、可验证的加密日志，记录所有合规 CA 机构颁发的所有证书。这些日志使得每个已颁发的证书都变得可观察、可审计。

下图说明了这个过程：

图 1：证书签名和颁发过程

以下是更详细的步骤：

• 在 CSR 生成期间，网站所有者生成 CSR 请求 CA 机构颁发 TLS 证书。

• 在证书颁发期间，CA 机构验证请求并颁发 TLS 证书。

• 在日志提交期间，CA 机构将证书（或预证书）提交给一个或多个 CT 日志，都是公开的、仅限追加的数据结构（通常是Merkle树），其中存储了证书，可供任何人查询。Merkle 树是一种加密数据结构，可确保日志只能追加且不可篡改。

• SCT 是 CT 日志以加密方式签署的承诺，声明其已经接收证书并将该其纳入了日志。

• 提交后，CT 日志将 SCT 返回给 CA 机构。

• SCT 被发送，嵌入到最终的证书中或在 TLS 握手期间提供。

• 像 Chrome、Firefox 和 Safari 这样的浏览器会拒绝或标记没有有效 SCT 的证书，它们是信任所必需的。

• 域名所有者使用工具主动检测 CT 日志中的恶意证书或错误颁发的证书。

这种方法为什么有效

通过加密保障机制（Merkle 树与公共日志（CT 日志））和浏览器强制执行相结合，该生态系统使得 CA 机构几乎不可能秘密颁发欺诈性证书而不被发现。

构建一个安全的 CT 生态系统

在实践中，要使 CT 发挥作用需要的不仅仅是日志，还需要一个由监控器、审计器和客户端组成的系统。

• CT 日志必须遵循严格的要求：仅限追加、加密包含证明、高可用性和日志轮换机制。

• 监控器不间断地监视日志中的新证书，如果出现流氓证书，就会提醒域名所有者。

• 审计器验证日志的完整性（即日志条目既没有被删除也没有被篡改）。

• Gossip 协议检测日志不当行为。例如，不诚实的日志可能向不同的客户端提供不同的视图。Gossip 协议可以对这些视图进行交叉验证。

例如，谷歌运营着多个生产级的 CT 日志。任何现代浏览器，如 Chrome，都需要至少两到三个来自独立日志的 SCT，才会认为 EV 和 DV 证书是有效的。

注：扩展验证（EV）证书提供增强的身份验证，而域名验证（DV）证书只验证域名所有权。

以谷歌 Chrome 的策略为例，它要求所有公开可信的 CA 机构都必须提交 CT 日志，并在 CT 截止日期（例如 2018 年 4 月强制执行）后拒绝没有有效 SCT 的证书。

CT 实践

证书透明度不再只是一种理论，而是一个运营基础设施，为工程师们提供了以下工具：

• crt.sh是一个搜索界面，可以搜索多个 CT 日志。输入域名就可以查看所有曾经颁发的证书。

• 谷歌的证书透明度日志列表列出了所有受信任的日志、它们的运营商和状态。

• 开源库项目，如certstream、go-ct等，帮助用户构建自定义监控器和审计器。

• 大型组织并未采用自动化手段将证书监控整合到其持续集成/持续交付（CI/CD）安全管道中（例如在新证书出现时触发警报）。

现实世界的 CT 应用包括：Facebook 运行着自己的监控器；Cloudflare 将 CT 检查集成到其 TLS 接入过程中；Let’s Encrypt 要求将所有已颁发的证书提交到 CT 日志。

证书透明度入门：给工程师的实用小技巧

• 在公共 CT 日志中监控你的域名：使用crt.sh或 Certstream 等工具发现为你的域名颁发的证书，并及早发现未经授权的颁发行为。

• 将 CT 监控集成到你的 CI/CD 管道中：当域名出现新证书时自动触发警报，实现对潜在错误颁发或影子 IT 风险的快速响应。

• 利用开源库：使用certstream或ct-tools等项目构建自定义监控器或将 CT 检查集成到你的安全工具中。

• 了解浏览器策略：确保颁发的证书符合主要浏览器的 CT 要求（如 Chrome、Safari），避免出现意想不到的信任问题。

图 2：端到端证书透明度工作流程说明 [点击此处查看大图]

通过 GitHub Actions 实现 CT 监控

自动化 CT 在 DevOps 管道中的可见性

为了在生产中实现 CT 审计，团队可以使用 GitHub Actions 自动化证书监控。以下是一个针对你的域名检测可疑证书的工作流示例：

yaml # .github/workflows/ct-monitor.ymlname: Monitor CT Logson:  schedule:    - cron: '0 */6 * * *' # 每6小时  workflow_dispatch:jobs:  check-certificates:    runs-on: ubuntu-latest    steps:    - name: Check issued certs from crt.sh      run: |        DOMAIN="example.com"        curl -s "https://crt.sh/?q=${DOMAIN}&output=json" | jq -r '.[].common_name' | sort -u > certs.txt    - name: Compare with known cert list      run: |        comm -13 known-good-certs.txt certs.txt > suspicious.txt        if [ -s suspicious.txt ]; then          echo "::error ::Potential unknown certs detected!"          cat suspicious.txt          exit 1        fi

在 CI/CD 或事件响应中验证 SCT

在审计期间手动验证 SCT：DevOps 团队可以在事件分级处理或证书部署的过程中，通过检查 PEM 证书中嵌入的 SCT 来验证 SCT 的存在。

代码片段：

#!/bin/bashCERT_FILE="your_cert.pem"openssl x509 -in "$CERT_FILE" -noout -text | grep -A 10 "Signed Certificate Timestamp"

未来之路：不断演变的互联网信任机制

CT 不是万能的，它只是一个基础。未来的创新将旨在弥合现有的信任缺口：

虽然在将开放性带入 Web PKI 方面，CT 是一个里程碑，但该生态系统仍在发展。有一些新的提议和实验工具旨在解决 CT 的盲点，并将其扩展到新的信任域，以下是未来展望。

Static Sunlight API：将 CT 引入静态环境

有一项新的创新是Static Sunlight API，旨在使 CT 日志包含数据在无法查询实时日志的环境中也能被访问，例如移动设备、物联网系统以及连接受限的边缘基础设施。

其思想是生成 CT 日志快照或离线创建 Merkle 树证明，然后嵌入到客户端或浏览器中并进行静态验证。这种方法在证书验证期间不依赖于实时 CT 日志服务器，实现了更多保护隐私的审计跟踪。

例如，浏览器可以每隔几天获取一次阳光快照（Sunlight Snapshot ），并缓存证书包含证明，从而实现离线 SCT 验证而又不牺牲透明度。

委托凭据：最小化密钥暴露

长期存在的 TLS 证书带来了运营风险：如果私钥泄露，攻击者就可以冒充服务器达数月之久。委托凭证（DC）允许证书持有者生成由主证书签名的短效一次性凭证，有效缓解了此类风险。

这些委托凭证的寿命只有几个小时或几天，并通过 TLS 握手分发。这种方法：

• 最大限度地降低了长期密钥泄露的风险

• 与临时密钥和内容分发网络（CDN）配合良好

• 已经得到 Cloudflare 和 Mozilla 的支持

当搭配证书透明度（CT）时，这些凭证仍然可以被记录和监控，保持了透明性。

后量子证书：CT 遇见 PQC

随着量子计算的临近，传统加密算法如 RSA 和 ECDSA 面临着风险。后量子密码学（PQC）引入了新的签名方案，如 Dilithium 或 Falcon，CT 需要跟上这种发展。

在不断演变的密码学领域中，当前正在进行的研究聚焦于增强 SCT 的安全性和弹性。人们正努力将 SCT 嵌入到结合量子抗性和传统密码学算法的混合证书中。此外，还有一项正在进行的工作是提高日志服务器对量子伪造证明的鲁棒性，确保在出现高级量子攻击的情况下证书透明度日志的完整性。最后，为了有效监控和跟踪已为 PQC 做好准备的部署，推动向量子安全基础设施的平稳过渡，混合日志的审计方法也在开发当中。

谷歌已经在特定域中使用 CT 兼容性扩展实验了后量子 X.509 证书。

Gossip 协议和审计

当前部署的 CT 机制依赖于“信任但验证”原则：审计器和监视器自动检查日志一致性。但若日志存在选择性造假呢？Gossip 协议应运而生。

像 CT-over-DNS 或全网 Gossip 协议（如谷歌的 Trillian Gossip）这样的工作旨在：

• 在浏览器、监控器和日志服务器之间交叉验证 SCT

• 检测分视图攻击或日志回溯

• 信任机制进一步去中心化

对生态系统的健康而言，这个领域至关重要，最终可能会被浏览器和 CA 机构强制要求。

重新构想 CA 治理：ARPKI 及其它

也有一些正在进行的研究工作旨在彻底重新思考如何选择和治理 CA，特别是：

• ARPKI（攻击弹性 PKI）提议，要求多个 CA 机构共同签署每个证书

• Namecoin 和其他基于区块链的想法尝试去中心化的名称/证书绑定

• 基于安全飞地（Enclave-based）的 CT 日志记录（如 SGX）增强了日志的不可变性

虽然它们还不是主流，但表明了一个愿望，即分散信任，使其不受单点故障所影响，特别是在地缘政治或经济事件可能影响 CA 机构独立性的世界中。

图 3：CA 世界的未来发展

参考资料与延伸阅读

• 证书透明度项目（谷歌）是 CT 生态系统的官方网站，包括日志列表、CT 政策和开发者文档。

• RFC 6962 - 证书透明度（IETF）：定义 CT 日志、签名证书时间戳（SCT）和包含证明的基础规范。

• RFC 9162 - 证书透明度（IETF）取代了 RFC 6962。它还指定了一个新的 TLS 扩展，用于发送各种 CT 日志工件。但是，所有主要的浏览器，如 Chrome、Firefox，都尚未采用它。

• crt.sh是 Sectigo 提供的一个证书搜索工具，它提供一个可搜索多个 CT 日志的界面，适用于发现错误颁发和域名证书历史。

• 谷歌Chrome证书透明度政策包括要求 CA 机构遵守 CT 合规性以获得 Chromium 浏览器的信任。

• Let's Encrypt CT文档描述了最大的 CA 机构如何实现和支持 CT 日志记录。

• Facebook的CT监控基础设施（以及其它进一步的文档）描述了如何构建可扩展的内部 CT 监控。

• Static Sunlight API（下一代 CT 监控）提供了一种新颖的方法，使用预计算的日志数据快照进行可扩展的 CT 聚合和审计（另见github项目）。

• ZLint - X.509证书的证书Linter是一个开源工具，用于检查和验证证书字段和合规性。

• 谷歌的审计工具Monologue验证 CT 日志的一致性和可靠性。

• Certstream提供实时的 CT 日志流。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：

https://www.infoq.com/articles/tls-certificate-transparency/