证书透明度(CT)是一项仍在发展中的技术，用于检测Web上错误颁发的证书。很酷很有趣，但是很复杂。我做过关于CT的演讲，我参与过Chrome的CT实现，我积极参与解决正在进行的部署挑战--即便如此，我有时还是会忘记这些部件是如何组合在一起的。我发现很容易忘记系统是如何防御特定攻击的，或者某个特定机制的目的是什么。
这篇文章的目的是从头开始建立一个关于CT的高级描述，解释为什么所有的部件都是这样的，以及它们是如何组装在一起的。这些材料大部分来自我与同事克里斯·帕尔默(Chris Palmer)在斯坦福大学(Stanford)网络安全课程中所做的客座演讲(CT部分从幻灯片52开始)。
证书颁发机构(CA)是浏览器信任的组织，在检查收到证书的人确实拥有他们的域之后，为域名颁发证书。CA可以是公司和政府，也可以是偶尔的非营利性组织。CA颁发坏证书相当常见。与任何组织一样，CA有时会犯错误，有时会受到损害或恶意。有时证书会被正确地颁发，而CA根本不会做任何错误的事情：流氓内部人员、BGP劫机者或倒霉的供应商可能会为他们不做的域申请证书。
安全界已经发明了各种机制来阻止浏览器接受这些“未授权”的证书。例如，服务器操作员可以一次性使用公钥锁定来限制可以为其域颁发证书的CA，这样就不会仅仅是任何CA妥协都会将他们置于危险之中。(不幸的是，PING原来是一把巨大的步枪，从未得到广泛采用，目前正在垂死挣扎。)。
然而，阻止浏览器接受错误提交的证书只是难题的一部分。检测错误的证书也很重要。例如，在2011年，一名攻击者侵入了DigiNotarCA，并不正当地颁发了一个通配符Google.com证书，他们用该证书来攻击伊朗的受害者。虽然谷歌Chrome浏览器由于公钥锁定而不接受证书，但谷歌只是偶然发现了这一攻击，因为一名用户在帮助论坛上发布了关于该错误的帖子。这真是千钧一发：如果不是那个用户碰巧报告了，还会有人知道这次攻击吗？
因此，对检测遗失证书的技术手段的渴望由此而生。如果域所有者可以检测到他们的域的未经授权的证书，他们可以吊销1未授权的证书。如果由于CA行为不当而发生故障，域所有者可以将该事件报告给浏览器或操作系统供应商，后者可能会选择不再信任CA颁发证书。
域的未经授权证书并不是唯一的故障类型。CA可能会创建不好的证书，因为它们使用过时的密码算法，违反证书的最长生存期或应该使用的特定编码等规则。如果浏览器供应商可以检测到这些类型的错误(不一定是恶意的，但卫生状况不好的迹象)，他们可以要求CA修复这些问题，甚至在适当的时候删除它们。
允许检测坏证书的最简单尝试是要求CA发布它们颁发的每个证书的列表。他们可以自己直接发布证书，也可以将其转发给其他发布证书的服务。域所有者可以监控每个CA颁发的证书是否有未经授权的证书，浏览器管理员/研究人员等可以监控每个CA的卫生状况不佳。
但我们试图解决的根本问题是，CA可能会被泄露、恶意或容易出错，因此我们不能仅仅依赖CA发布自己的证书。颁发邪恶证书的邪恶CA根本不会发布该证书。
在稍微健壮的系统中，CA可以将每个颁发的证书提交给证书发布者。发布者将返回证书上的签名，并提供它所看到的可公开访问的证书提要。浏览器只接受带有受信任发布者签名的证书。这有点接近CT的样子，但仍有许多问题需要解决。
此发布者签名系统的一个小问题是，CA需要时间将每个证书提交给这些发布者，并在颁发证书之前验证其是否已登录。(稍后将会清楚，记录证书可能需要对大型数据结构和全局Writeconsensus执行操作，这可能需要几分钟或几个小时。)。CA不希望其他服务在证书颁发的关键路径上运行速度可能很慢，这是他们的核心赚钱业务操作-他们的客户也不希望这种速度减慢，因为一些Web服务器依赖快速的证书发布来满足业务和正常运行时间的要求。因此，在CT中，来自这些发布者之一的签名(称为CT日志)实际上并不保证日志已经发布了证书。相反，日志会发出一个签名的CertificateTimestamp(SCT)，这是一个签名声明，表示日志已经看到证书，并承诺在它提供的时间戳后24小时内发布它。
到目前为止，我们建立的系统是这样的：CA向日志提交证书，日志返回SCTS，承诺在24小时内发布证书。浏览器不接受证书，除非它们带有来自受信任日志的SCT。感兴趣的各方，如域所有者或研究人员，可以监控日志发布的恶意证书数据。
现在的关键问题是：我们为什么要信任日志？如果CA可能会受到损害、恶意或容易出错，为什么日志不能也受到损害、恶意或容易出错呢？甚至可以想象日志和CA合谋颁发恶意证书。CT的设计者希望日志不可信，这就是CT变得复杂的原因。
作为从日志中删除信任的一种简单方法，浏览器可能需要每个证书不同日志中的多个SCT。使用此策略，攻击者将不得不危害多个日志，以防止它们中的任何一个发布恶意证书。然而，在实践中，很难说是什么构成了不同的日志。如果同一组织控制多个日志并与攻击者勾结，则多日志策略无济于事。Chrome目前部署CT的策略是“一个谷歌，一个非谷歌”：每个证书必须至少附带一个来自谷歌操作的日志的SCT，以及一个来自非谷歌操作的日志的SCT，前提是攻击者很难泄露两个这样的日志。然而，这一政策一直是临时措施，直到技术上更健全、组织上更中立的东西能够到位。
要理解如何以更合理的技术方式从日志中移除信任，我们需要思考一个深层次的问题：“发布”证书实际上在技术上意味着什么？每个日志都有一个生成证书提要的API端点-但是，直观地说，在某个特定时间点将该端点上的证书提供给一个客户端是不足以“发布”该证书的。要真正发布证书，该端点必须在日志为证书签署SCT之后的任何时间向查询它的任何人提供证书。要验证日志是否真正发布了证书，我们需要每个人有效地与其他每个人核对，确认他们在从该端点接收的提要中看到了证书。这里的“每个人”包括正在验证TLS证书的终端用户设备，以及研究人员、浏览器供应商、域所有者和其他任何对监视日志提要以查找未提交证书感兴趣的人。
当然，要求每个人维护每个日志发布的所有证书的列表并相互检查以比较整个序列是否匹配是不切实际的。这可能是数十亿台设备，每台设备都维护着数百万或数十亿份证书。此外，这些实体中的一些可能只对非常小的证书子集感兴趣；例如，域所有者只对监视自己域的未注册证书感兴趣，而没有兴趣做大量工作来帮助其他实体验证是否正确发布了不相关的证书。
假设日志可以生成它发布的证书序列的简短摘要。摘要类似于加密哈希：如果您可以提供生成给定摘要的证书序列，则无法找到生成相同摘要的任何其他序列。与普通加密哈希不同，这些摘要具有两个特殊属性：
如果日志生成摘要，则可以添加更多证书并生成更新的摘要，并有效地证明这两个摘要彼此一致，即后一个摘要的底层证书序列是前者的超序列。
添加证书后，当要求提供它已发布的证书的当前摘要时，日志可以提供摘要包含该证书的有效证据。
这个神奇的摘要是任何观察日志的人都需要保持的状态，以便能够与其他所有人一起验证他们关心的证书是否已经发布。例如，验证TLS证书的Web浏览器可以请求摘要以及当前证书包含在该摘要中的证明(属性#2)。当浏览器遇到更多证书时，它可以请求更新的摘要以及每个证书的证明，并且它始终可以验证最新的摘要是否与其先前的摘要一致(属性#1)。浏览器所要做的就是跟踪单个最新的摘要，任何人都不可能生成映射到该摘要的证书序列，该序列不包括浏览器已验证的证书。然后，两个不同的浏览器用户可以彼此交换摘要并验证其一致性(属性#1)，以验证每个浏览器用户看到的证书是否已发布给对方。
这既神奇又令人费解，因为浏览器用户Alice能够验证他们看到的所有证书是否都“发布”给了浏览器用户Bob，而浏览器用户Bob从未看到过这些证书中的任何一个，反之亦然。也就是说，除非日志中还包含Bob看到的所有证书，否则日志将无法生成与Alice的摘要一致的证书提要。
实际上，浏览器用户不太可能下载整个日志中的证书(为什么要下载呢？)。取而代之的是，其他实体监视整个提要：浏览器供应商、研究人员和被称为“监视器”的服务，帮助帮助域所有者监视其域的未经授权的证书。因此，一旦浏览器用户Alice验证了他们的摘要与浏览器用户Bob的摘要一致，Alice就可以与监视器的摘要(例如，监视器的摘要)进行一致性检查，以验证监视器(监视器正在查看日志发布的所有证书)是否已看到Alice和Bob看到的所有证书。
我认为这些摘要在某种程度上是一个累加器，可以吞噬越来越多的证书，而不会增加2的大小。一旦您验证了给定摘要中包含证书，您就可以不断将该摘要更新到最新版本，并且如果您检查与以前摘要的一致性，您就永远不会丢失当前摘要包含该证书的属性。(=。当您将您的摘要与其他人的摘要进行比较时，您的摘要将吸收他们看到的所有证书，现在您永远不会丢失当前摘要包含您的所有证书及其所有证书以及他们与其检查过摘要的任何人看到的所有证书的属性。这是真的，即使你从未见过这些证书！由于这种累积性-用别人的摘要验证您的摘要会累积他们对您的摘要所做的所有验证-大量参与者可以高效地检查他们是否每个人都看到了其他人看到的证书。这就是我们所谓“发布”证书的真正意思。
可悲的是，我刚才描述的并不是所有的东西现在都实际部署到了现实世界中。目前，Chrome和其他一些浏览器需要一些SCT来信任特定日期之后颁发的任何公共证书。这是一个重要的里程碑，因为所有主要的CA现在都默认记录了绝大多数新颁发的证书。然而，还有很多工作要做。
验证给定证书是否包含在摘要中称为SCT验证，目前还没有主流Web浏览器实际执行此操作。安德鲁·艾尔在“波斯顿邮报”上谈到了如何部署它，以及为什么它具有挑战性。
我所称的摘要实际上称为签名树头(STH)。我谈到了生态系统中的不同方面，交换他们的摘要/STH，并检查彼此的一致性。这可以防止所谓的“拆分视图攻击”，即日志向使用证书攻击的客户端呈现包含恶意证书的STH，以及向监控误操作的客户端呈现完全独立的STH(不包括恶意证书)。“拆分视图攻击”是指日志向正在使用证书攻击的客户端呈现包含恶意证书的STH，以及向监控误操作的客户端呈现完全独立的STH，该STH不包括恶意证书。有人试图定义用于交换STH的八卦协议，但它们还没有被广泛部署。最有可能的是，集中化将成为关键。不太可能每个浏览器用户都会与每个其他浏览器用户八卦STH，但对于少数浏览器供应商来说，更可行的做法是彼此八卦，然后将这些八卦的STH分发给他们的用户。
CT的基本魔力是Merkle树。这是一种古老而简单的密码结构：哈希树。CT使用一个简单的过程用新证书更新树，这个简单的构造给出了我上面描述的两个神奇属性。CT中看似最神奇的部分实际上相当真实，但在现实世界中大规模部署却是最困难的部分。
只是他们不能，真的。吊销证书不像警告CA那么简单，CA然后通过OCSP或CRL分发吊销数据。一些浏览器使用自定义列表；Chrome主要用于分发中间证书和/或高价值终端实体证书。一般来说，域名所有者对是否以及如何分发撤销信息有相当模糊和特定于浏览器的保证。因此，普通网络开发人员的社区仍然缺少一个剧本，告诉他们如果在CT日志中发现他们的某个域名的未经授权的证书该怎么办。-↩。
虽然摘要的大小不会增加，但证明的大小会增加(与日志发布的证书数量成对数关系)。-↩