证书透明化的工做原理

[TOC] 译：How Certificate Transparency Works

证书透明为当前的SSL证书系统增长了三个新的功能组件：

• 证书日志
• 证书监控
• 证书审计

这些功能组件表明了能提供补充的监控和审核服务的离散软件模块。他们不替代当前的SSL证书系统，也不做为一个选择。实际上，这些组件没有改变基础的信任链模型--让客户端验证域并与服务器创建安全的链接。相反，这些组件经过支持整个SSL证书系统的公开监督和审查扩充了信任链模型

日志基本功能

证书透明系统的中心在于证书日志。一天证书日志是一个简单的网络服务，保存了一条SSL证书记录。证书日志有三条重要的特性：

• 只能追加--证书只能被添加到日志中；证书不能被删除，修改或追溯地插入到日志中。
• 加密确认--日志使用特殊的Merkle Tree Hashes加密机制来防止篡改和违规行为。
• 公开审核--任何人都能查询一条日志而且验证日志的行为，或验证SSL证书已被正确地添加到日志中。

日志数量没必要太大：须要足够的日志来保证日志失败或临时中断，可是还不能多到让监控变的困难--例如，超过10条但远小于1000条。每条日志的操做要独立于其余日志（也就是，日志间没有自动复制）。

日志的只能追加的性质容许使用特殊类型的加密哈希来验证日志没有损坏，而且这条日志中没有删除或修改任何证书的操做。这种特殊的哈希--Merkle Tree Hash--也能让审计发现是否有人分叉了日志或向日志中注入过时的证书。关于哈希机制的更多信息看证书透明化日志工做原理。

每条证书日志必须公开地公布其URL和公钥（除此以外的其余东西）。任何人均可以经过HTTPS的GET和POST消息与日志交互。

日志基本操做

任何人都能向日志提交证书，尽管大多数证书被证书机构和服务器运营商提交。向日志提交有效证书时，日志以签名证书时间戳(SCT) 回应。SCT是一个在某个时间段内将证书添加到日志中的简单的保证。这个时间段称做最大合并延迟(MMD)。

MMD有助于确保日志服务器在合理的时间段内将证书添加到日志中，而且不会阻塞证书的发布和使用，同时容许日志为了弹性和可用性运行分布式服务。SCT伴随证书的整个生命周期。特别是，TLS服务器必须在TLS握手期间将SCT和证书一块儿交付。

证书透明支持三种交付带有证书的SCT方法，每种的描述以下：

X.509v3扩展

证书机构（CA）使用X.509v3扩展将SCT附加到证书上。图一展现了工做流程。证书机构向日志中提交预认证，而且日志返回SCT。CA而后将SCT做为X.509v3扩展附加到预认证中，对证书签名，而后将证书交付给运营商。

该方法不须要任何服务器更改，使运营商能够像以往同样继续管理其SSL证书。

TLS扩展

运营商可使用特殊的TLS扩展交付SCT（图2）。这种状况下，CA将证书颁发给服务器运营商，而后服务器运营商将证书提交到日志中。日志将SCT返回给运营商，而后在TLS握手期间，运营商使用带有签名证书时间戳（signed_certificate_timestamp）将SCT交付给客户端。

这种方法没有改变CA颁发SSL证书的方式。然而仍然须要服务器以适应TLS扩展作出改变。

OCSP装订

运营商也可以使用在线证书状态协议（OCSP: Online Certificate Status Protocol）装订来交付SCT（图2）。这种状况下，CA同时向日志服务器和运营商颁布证书，而后运营商向CA进行OCSP查询，CA返回SCT，在TLS握手期间服务器将SCT包含在OCSP扩展中。

这种方法容许CA对SCT担责，可是不能延迟颁布证书，这是由于CA能异步地收到SCT。可是，确实须要修改服务器才能进行OCSP装订。

监视器和审计的基本操做

监视器监控日志中可疑的证书，像非法或未受权的证书，不正常的证书扩展，或者奇怪权限的证书（举例，CA证书）。监视器也验证全部已记录的证书在日志中可见。经过周期性地获取已被添加到日志中的全部新条目来作到这一点。所以，大多数的监视器能彻底复制监控到的日志。若是一条日志长时间地处于脱机状态，且监视器有该条日志的副本，监视器就能做为只读的备份日志，向查询该日志的其余监视器和审计提供日志数据。

审计验证日志的总体完整性。有些审计也验证日志中是否有特定的证书。经过周期地获取和验证日志证实来作到这一点。日志证实是被加密哈希签名过的，以证实日志的良好性。每条日志必须按需提供他们的日志证实。

审计能够用日志证实来验证日志的新条目已被添加到日志旧条目中，而且无人能经过追溯地插入，删除，或更改证书来损坏日志。审计也使用日志证实来验证日志中的特定证书。这尤为重要，由于证书透明框架须要全部的SSL证书被登记到日志中。 若是TLS客户端肯定（经过审计）日志中没有证书，可使用日志中的SCT做为日志未正确运行的证据。关于日志证实的更多信息看证书透明化日志工做原理。

尽管日志证实容许审计或监视器验证特定日志的视图和以前视图的一致性，他们也须要和其余监视器和审计验证特定日志的视图的一致性。为了方便证实，审计和监视器经过小道消息协议来交换日志信息。异步通讯路径帮助审计和监视器发现分叉的日志。

典型系统配置

证书透明性框架没有规定现有SSL证书系统中监视器和审核器的任何特定配置或位置。也就是说，一些配置比其余配置更常见。在典型的配置中，CA运行监视器，客户端（浏览器）运行审计（图3）。这种配置简化了监控和审计间必要的消息，且让证书机构和客户端开发监控和审计系统，以知足客户和使用者的特殊需求。下面介绍一些驱动该配置的过程。

证书颁布

CA得到日志中的SCT，经过X.509v3扩展将SCT合并到SSL证书中（详细过程看图1）。而后CA向服务器运营商颁布证书（附有SCT）。该方式须要没有服务器更新（全部的当前服务器支持X.509v3扩展），且让服务器运营商像管理SSL证书的一样方式来管理他们的证书。

TLS握手

TLS握手期间，TLS客户端接收SSL证书和证书的SCT。一般，TLS客户端验证证书和签名链。另外，TLS客户端验证SCT上的日志签名，以验证SCT是由有效的日志发布的，且SCT其实是为该证书（非其余证书）颁布的。若是有异样，TLS客户端可能会拒绝证书。举例，TLS客户端一般会拒绝SCT时间戳还未生效的证书。

证书监控

大部分的监视器由证书机构操做。经过配置，证书机构构建根据自身的特定监视标准和要求进行定制的有效的监视器。

证书审计

大部分的审计可能内置于浏览器中。在此配置中，浏览器会按期批量地发送SCT到其集成的认证组件，而且询问这些SCT（和相应的证书）是否被正确的添加到日志中。以后审计异步地拿到日志并执行验证。

其余系统配置

除了上述典型的配置觉得，监视器和审计与现存的TLS/SSL组件紧密集成，证书透明支持多种其余的配置。例如，审计可做为独立实体运行，向证书机构和服务器运营商提供有偿或无偿的服务（图4）。监视器也能够经过服务器运营商运行，像大型的互联网公司谷歌，微软，或雅虎。一样地，设计也可做为独立服务运行，也但是监视器的第二功能。