证书透明度（Certificate Transparency）

最新推荐文章于 2024-04-26 10:52:53 发布

Stride Max Zz

最新推荐文章于 2024-04-26 10:52:53 发布

阅读量2.1k

点赞数 4

分类专栏：证书文章标签： ca证书证书透明度

本文链接：https://blog.csdn.net/qq_35324057/article/details/114293734

版权

证书专栏收录该内容

2 篇文章 0 订阅

订阅专栏

写在前面

最近在整理有关证书透明度的知识，现将其记录下来。我将从以下几个方面去介绍CT：

背景故事
发展阶段
整体框架
- CT log
- Merkle Tree
- Monitors—Merkle Consistency Proof
- Auditors—Merkle Audit Proof
- Precertificate
- Publishing Certificates into CT logs
总结
参考

背景故事

我想先从TLS谈起，其前身是SSL由Netscape公司提出，是一种加密协议，提供端到端通信的数据保护功能，我们常见的https协议，就是在http基础上增加TLS继而提供Web浏览器和服务器之间的安全通信。TLS经历了很多版本更替，目前最新的TLS1.3在2018年8月颁布（标准化，rfc8446）。谷歌透明度报告称，在所有谷歌产品和服务中已有超过95%的流量被加密（透明度报告）。
在端到端的通信加密中最薄弱的环节是如何确定通信一方的身份，也就是他是不是他的问题。在TLS中采用证书(certificate)来弥补这个漏洞。但是，也存在一些问题，比如：颁发某个域的证书，并不会通知该域的所有者；同时，令人信服的CA（certificate authority）可能会被攻破或者与攻击者合谋。于是，精明的坏蛋们又对证书下手做了许多坏事情。2011年八月，荷兰CA安全证书提供商DigiNotar的服务器被发现遭到黑客入侵。黑客为包括谷歌在内的超过530个网站颁发了伪造证书。证书是有效的，因此可以实施MITM攻击。DigiNotar 因为这次攻击而失去信任并宣告破产。除此之外，土耳其和法国都曾报道过由可信CA颁发未经授权证书的案例。
所以，当前的数字证书管理系统中缺陷使得欺诈证书导致安全问题和隐私泄露风险变得日益明显。因此，证书透明度被提及出来，作为证书生态系统的辅助工具，缓解证书错误颁发；减少安全问题以及隐私泄露的发生。

发展阶段

在2013年被提及出来（rfc6962）
在2016年提出CT 2.0（draft-ietf-trans-rfc6962-bis-22）

整体框架

证书透明度我们可以理解成一个用于公开审查证书的框架，里面包含一个公开审计、只能添加证书和防篡改特性的数据库CT logs，证书颁发机构CA，website可以说是domain owner，客户端即browser，还有用于审查CT logs的Monitor和Auditor。我将该框架整理成一张图，下面逐个介绍。
CT 总结

CT logs

logs可以接受已过期、尚未生效、已被吊销或在其它方面并非完全有效的证书。但是，必须拒绝发布没有到已知根CA的有效验证链证书。
logs一般会指定接受的根CA列表。

三大特性：

Append-only
Cryptographically
Publicly auditable

并且logs会定期将新添加的证书合并到logs中；

logs承若将在最大合并延迟（MMD）的固定时间范围内，将证书合并到Merkle Tree中去。

Merkle Tree

Merkle tree看起来非常像二叉树，中文是默克尔树，其叶子节点上的值通常为数据的哈希值。非叶子节点上的值是对该节点的两个孩子节点串接起来进行哈希。不仅可以快速进行完整性验证，而且还能进行快速数据对比，找出不一致地数据。在证书透明度框架中的CT logs使用Merkel Hash Tree存储证书，每个叶子节点都是一个证书的散列值。同时也可以进行有效的审计。使用的哈希算法是sha-256。

Monitors—Merkle Consistency Proof

Merkle Tree 的一致性证明，是为了验证CT logs的只添加特性（append-only）。意味着只能添加证书进去，而不能修改或者删除里面的证书。CT logs会每隔一段时间自动将新添加的证书更新到Merkle Tree中，为了验证该特性，就需要验证变化前的树是否是变化后的树的子集，并且新添加的条目都位于旧树的后面。也可以理解为是否对新添加的树完成了Merkel Tree的计算。如下图所示：
consistency
CT log p是旧版本，q为新版本，新添加了g，h两个证书，则重新计算该Merkle Tree的节点l,n，最终我们计算得到H’，同时也可以计算H，这两个版本的树头我们叫做Signed Tree Head，如果我们计算得到的树头H’和H与logs发布的STHs相同，则证明了新版本与旧版本的一致性。

Monitor
它会监视所有logs，并且检查是否存在异常行为和可疑证书。检查每个日志中的每个新条目。它可能想要保存整个logs的副本，以便检查。同时，它还进行一致性检查。为了完成以上工作，它会向logs索取STHs，以便进行验证。

Auditors—Merkle Audit Proof

该证明主要是为了验证某一个证书在不在logs中，一般由Auditor完成。在这一验证过程中，auditor需要知道logs中Merkle Tree的节点列表，以及要验证证书在Merkle Tree中的路径，这样我们才可以计算相应的散列值。
auditor proof
如上图中，要验证证书c2在该Merkle Tree中：

首先计算该证书的散列值c
其次，将其与其兄弟节点的散列值d串接，计算得到父节点的散列值j
然后，同第二步原理，计算得到m和H
最后，比较H和log发布的STH比较，如果一致，则证明该证书c2存在于该树中

Auditor
可以看作是Monitor的第二功能，或者是TLS 客户端的组成部分。因为，在框架中我们可以看到，browser可以通过Auditor来查询从server获得的SCT（Signed Certificate Timestamp），进行Merkle Audit Proof，证明该证书是否在logs中，从而做出判断。它首先向logs请求该证书在树中的索引和audit path（base64编码的Merkle Tree节点数组，证明包含该证书），然后再计算并判断。

Precertificate

为了提供一种在证书正式颁发之前就放进logs中的手段，CA先将Precertificate提交到logs，获得对应的SCT。该证书与普通证书的区别在于其存在一个poison extension(OID 1.3.6.1.4.1.11129.2.4.3)从而使其无效。预证书提交必须随附预证书签名证书（如果使用），以及所有必要的附加证书，以验证链，直至达到可接受的根证书，即预证书的错误签发等同于最终证书的错误签发。

按我的理解，CT logs中存放的证书有两种：Precertificate和certificate。前者是证书颁发前提交到logs，后者是已经颁发的证书提交到logs。

Publishing Certificates into CT logs

有关提交到logs证书的类型有两种：certificate和precertificate。

有关提交的方式有三种：

CA还未正式颁发证书之前，将precertificate提交到logs，logs返回SCT，CA将其嵌入最终的证书中。
证书已经颁发给server，server将其提交到logs，logs返回SCT，server在与client做TLS连接时，将其发送给client，以便client去检查。
CA颁发证书给server并且也将证书提交到logs，logs返回SCT，并加入OCSP（在线证书状态协议），在TLS握手过程中，由client查询ocsp，server返回SCT。

所以对应的有三种SCT传递方式：

X.509证书
TLS扩展—signed_certificate_timestamp
OCSP

其中通过证书扩展是最简单的方式，TLS扩展最快因为在clienthello发送的最早，OCSP是最麻烦的方式了。

Link between framework node

我想总结一下，在整个CT 框架中，部分节点之间的连接是常规的TLS连接，所以会存在一些问题。但是，大部分连接是基于CT logs中对STH和SCT签名的公私钥对。这种的安全性要比TLS连接高一些。

logserver-Auditor-Browser：客户端收到server发送过来的SCT，会交给Auditor进行审查，此时的SCT已经被log server用私钥签名。所以该路径的安全性较高。
logserver-Monitor-Auditor：来确定log server不出问题，Monitor和Auditor之间会交换从logs索取的STHs（其也被log server签名），来确定两者看到的视图是一致的。这就是gossip的主要功能，后面还会补充有关gossip的知识。
Monitor-Domain owner：domain owner依靠第三方的Monitor去观察可疑的证书时，Monitor提供搜索查询服务，客户可以查询可疑证书，他们之间也是常规的TLS连接，所以有人就这方面做了一些调查。
website-browser：这两者之间我们大家都熟知，是常规的TLS连接。

gossip

提出的主要目的是检查CT logs是否存在不当行为，比如：恶意的CT logs可以重写历史数据通过“split view”，顾名思义，给不同的client提供不同的视图，使得每个client都可以完成“consistency proof”以及“inclusion proof”。从而证明其“append-only”特征。所以需要一种机制来防止这种情况的发生。

提出了三种机制：