中科院DCS中心主导完成的学术论文《Certificate Transparency in the Wild: Exploring the Reliability of Monitors》被ACM CCS 2019录用接收。该工作第一次从CT Monitor可靠性角度对PKI证书透明化(Certificate Transparency, CT)应用现状进行系统深入的研究。
Google提出CT机制，联手Let"s Encrypt (免费CA机构)已经彻底颠覆了原有PKI数字证书服务领域。我们历时近2年的数据收集和实验研究分析表明，在Internet上提供证书查询/虚假证书监视服务的CT Monitor (CT的核心部件)，其服务质量都有明显缺陷、存在受攻击隐患；其中，Google和Facebook提供的Monitor平台尤其需要改进。CT的推广与大规模部署，还有很多技术问题需要解决。
传统PKI面临的挑战——虚假证书
PKI是互联网中最重要的基础性安全服务之一，成功部署在HTTPS服务、安全电子邮件、代码签名等解决方案中。截止到2019年7月，Censys统计结果显示，网络空间中出现过的数字证书数量已经超过18亿张，其中11.5亿由Let"s Encrypt签发；16.75亿已记录在CT日志中。
传统PKI系统假设CA机构完全可靠，将CA作为信任锚、负责证书签发。然而近年来一系列安全事件表明，CA由于各种原因(网络入侵/误操作/技术更新不及时)可能签发虚假证书。例如，荷兰CA机构Diginotar在2011年遭受入侵，签发了500余个虚假证书，包括*.google.com等。
虚假证书：证书可以被客户端(例如浏览器)严格验证通过，但是证书绑定的密钥对并不被证书主体(即域名所有者)拥有，被用于发起中间人攻击(Man-in-the-Middle, MitM)或身份冒用攻击。
传统PKI信任体系缺乏发现虚假证书的能力，使得虚假证书往往需要经过数周甚至数月才能被发现。此外，客户端对CA机构的信任是绝对的、无差别的，任何一个公共信任的CA机构签发虚假证书，都可能影响整个互联网的安全。因此，虚假证书严重削弱了PKI信任体系。
什么是证书透明化CT？
针对虚假证书产生的安全威胁，为了及时发现虚假证书，提高对CA机构的问责能力，Google于2013年提出了CT方案。近年来，在PKI系统引入透明化机制，已成为业界共识。CT已成为PKI增强机制中最重要且最活跃的研究方向之一。
CT基本思想：将所有CA签发的证书记录在公开可访问的日志中，客户端只接受公开发布的证书。目的是使CA签发的所有TLS服务器证书公开可见，能够被公开查询、审计。因此，虚假证书一旦公开发布，就可以被利益相关方(域名所有者)发现。
证书透明化(CT)框架
CT方案在PKI体系中引入以下新组件：
Log Server：公开日志服务器，接收CA、网站等提交的数字证书，签发相应的SCT，并在规定时间内将证书添加到以Merkle树结构构建的公开日志中。
Auditor：定期检查日志服务器是否按照策略运行，行为是否正确。
Monitor：持续/定期获取并缓存日志记录的每个证书信息，为域名所有者提供证书查询及监视服务，帮助发现可疑证书。
相比于传统PKI系统，CT框架不依赖于单一可信的一方；而是作为一个分布式系统，将信任分布到众多CAs、Log Servers、Auditors和Monitors。CT日志只负责记录CA等提交的有效证书，并签发SCT，不检查该证书是否由域名所有者授权签发。一个证书基于浏览器CT策略被提交并记录到多个日志中，获得多个SCT。浏览器在与网站建立HTTPS链接时，将对SCT进行检查；只有同时满足CT策略、且被可信CA签发的有效证书才会被接受。
可信CA签发的虚假证书在提交给CT日志获得SCT后，同样可以被浏览器验证通过。因此，CT本身不能防止CA签发虚假证书，而是依赖Monitor检查日志记录的证书，帮助发现虚假证书。任何利益相关方(域名所有者、可信第三方)都可以充当Monitor。
CT应用及部署现状
CT已经实现大规模部署与应用。目前网络中，Google和各大CA机构共部署/运行了80多个日志服务器，记录了28亿多条证书记录。此外，互联网中已部署多个第三方Monitor和Auditor服务。所有主流CA机构都已应用CT。多个主流浏览器和TLS软件已支持CT，包括Chrome，Apple，Firefox，OpenSSL，Nginx，AD Certificate Service以及Azure Key Vault等。截止到2018年2月，至少60%的HTTPS通信支持CT策略。
此外，Chrome浏览器以及Apple平台自2018年6月起，开始陆续强制执行CT检查，服务器端使用的不满足CT策略的证书，将不再被浏览器/平台接受。这将进一步推动CT快速部署与应用。
CT应用及部署现状
Acting as a Monitor: 要求与挑战
CT依赖Monitor发现虚假证书。如果Monitor在实现中存在漏洞/缺陷，则攻击者会利用漏洞规避Monitor对虚假证书的监测。如果存在一个虚假证书，由公共可信CA签发、满足CT策略，浏览器验证通过、却不能在Monitor上及时发现，则攻击者就能用于发起MitM或身份冒用攻击。不可靠的Monitor将影响到CT框架的安全效果：在TLS/HTTPS生态系统中，符合CT策略的证书本应更值得信任。
Monitor对发现虚假证书至关重要，我们期望它们是可靠的：对提供证书查询/监视服务的域名，可靠Monitor应能够及时从公共日志中检索/返回CA为该域名签发的、完整的有效证书集。一些第三方Monitor也声称可以为用户提供可靠的证书监视服务。
以上可靠性要求，带来了两个技术挑战：
a. Monitor应获取公共日志中记录的所有证书。公共日志之间大量重复记录证书，随着时间推移，记录数量急剧增加，导致Monitor可能难以从所有公共日志中获取记录，而是选择部分合适的日志集监视。被监视的日志集合，应该在满足Monitor对记录及时处理的同时，保证查询结果的完整性。
b. 域名可能以各种形式绑定在证书中(例如，通配符子域名)，Monitor应能够正确处理已获取的记录，并将查询域名相关的所有证书返回给服务请求方。
普通用户是否能独立充当Monitor？
我们从完整性、客户端CT策略、CA覆盖率等多个角度研究了各种类型的日志集，发现每种类型的Monitor可以在保证可靠性的同时，监视最小的日志集，从而减少额外监视开销。为此，我们首先分析了网络中部署的公共日志服务器、日志所记录的证书，以及日志所接受的CA等三个因素对运行Monitor产生的影响。在此基础上，提出了5种合理的日志集(例如，最大/最小集)，分别从Log来源/范围，证书/CA覆盖范围，所满足的客户端CT策略等角度，阐述了这些日志集的有效性；提供给Monitor监视使用。
我们以日志集为单位，从存储、网络带宽、计算等角度测量对充当Monitor的实体的要求。在对2018年近一年的CT数据分析表明，作为Monitor所需具备的能力(存储、计算、网络带宽)远远超出了大多数普通域名所有者拥有的：
截止到2018年10月，Internet上一共部署有80多个公共日志服务器，所认可的CA约700多个，记录的证书数量已超过28.7亿个。无论Monitor监视哪种日志集，开销都是巨大的。例如，Regular Log集合作为Monitor可以监视的最大日志集，包含了所有正在运行，且记录公共信任证书的日志，包含50个Log，27.7亿个证书，存储开销约15.31TB(平均一条记录5.93KB)，证书增长700万+每天，43.99GB每天，带宽5Mbps。Google-operated & Google-approved Log集合是Monitor可以监视的最小日志集，所有满足Chrome CT策略的证书都会被记录在该集合中：9个Log，18.7亿个证书，证书增长500万每天，28.29GB每天。
第三方Monitor服务是否可靠？
上述研究表明，普通域名所有者独立充当Monitor其代价是昂贵，且不切实际的。更合理的方式是依赖专业第三方Monitor提供可靠的证书监视服务。目前互联网中已公开部署且提供证书查询服务的主流第三方Monitor一共有5个：crt.sh、SSLMate、Censys、Google和Facebook Monitor。我们以2个测试域名以及Alexa排名前一百万网站域名为测试对象，对5个Monitor进行了研究，评估它们提供的证书查询服务的完整性。实验数据集共包含300多万个证书。
处理Monitor不同的查询策略。为公平测试5个Monitor的可靠性。我们首先完成以下工作：(a)定义对于给定域名，期望获得的证书范围；(b)探索5个Monitor查询策略及API接口，分别设计了自动化查询程序及数据处理工具，屏蔽差异，保证每个Monitor都能返回各自所能查询到的所有相关证书；(c)定义“参考集”近似于域名证书“完整集”。我们将5个Monitor对域名的证书查询结果的并集作为每个域名的“参考集”，分别对比每个Monitor得到证书集与“参考集”差异。(d)异常数据处理：过期/代码签名/测试证书、大小写敏感、证书去重。
第三方Monitor服务接口和查询策略
1．探索性实验。通过向Let"s Encrypt为2个测试域名申请102个证书(并提交给CT Log)，评估5个Monitor是否可以及时监视到这些证书。该测试是在已知每个域名的证书完整集的情况下实现，可以很好地评估Monitor表现。结果显示，除了Facebook，其它Monitor都可以在证书提交给日志的8个小时内查询到。Facebook存在较大延迟，最严重的情况，有21个证书是在5周后才被监视到。这一时间窗口足够敌手利用发起攻击。
2．热门域名实验。Alexa Top-1K网站，通常每个域名拥有数百个证书。这类测试是在未知每个域名的证书完整集的情况下进行。
实验结果表明，没有任何一个第三方Monitor可以保证返回公共日志中记录的所查询域名完整的有效证书集合。我们从两个角度评估Monitor的表现：(a)相比“参考集”，缺失的证书量，(b)证书查询不完整的证书数量。
证书查询量方面(a)，Censys表现最好，只有12.6%的证书缺失；而从域名证书查询完整性角度看(b)，crt.sh最佳，只有104个域名证书查询不完整。Google和Facebook Monitor表现最差：分别有52.3%、34.0%的证书缺失，域名证书查询不完整的数量分别是546，289。基于域名证书数量分布分析发现：更热门的域名(具有更多的证书)，Monitor查询不完全的概率更大。
3．普通域名实验。同实验2类似，但测试对象是Alexa Top-1M网站，更普通的域名，通常每个域名拥有的证书数量在1-100之间。相比热门域名，Monitor表现要好一些，但是依然没有Monitor可以保证返回所有查询域名的完整证书集。Censys在最好情况下，在Top-(100K-500K]区间抽样选取的1千个域名中，有0.1%的证书缺失，7个域名证书查询不全。Google和Facebook Monitor在表现最好的情况下，仍各自分别有6.7%，5.0%的证书缺失；其中Facebook Monitor总会有至少15%的域名的证书查询不全。
证书查询不完整的域名数量分布(Alexa Top-1M分组，每组随机抽样1千个域名)
需要注意的是，真实结果可能要比我们发现的更为严重，因为我们使用的“参考集”来自5个Monitor查询结果的并集、不是真正的证书完整集合。以上问题不仅会降低Monitor服务的可靠性，也会严重降低CT可靠性。
Monitor证书查询结果不完整原因分析
我们将上述发现分别报告给了每个Monitor。只有Censys给出了可能的合理解释：数据中心迁移导致部分查询结果缺失；其他Monitor没有给出答复、或有意义的答复。为此，我们尝试从外部分析得出可能的原因：
处理延迟：crt.sh，SSLMate(数据积压)，Censys(延迟一两天)
预证书处理存在问题：Google(Alex Top-1K域名中缺失的76.9%为预证书)
未及时恢复的事故：Censys(特定时间窗口，数据中心转移)，Google(特定时间窗口，原因未知)
不支持的域名：SSLMate(特定顶级域名)，Google(未知)，Facebook(无效或未查询到)
API查询返回上限：Censys (25000)，Facebook (5000)，SSLMate (超时未返回)
ACM CCS全称ACM Conference on Computer and Communications Security，是信息安全领域的国际四大安全顶级会议之一，也是中国计算机学会CCF推荐的A类国际会议。ACM CCS 2019将于2019年11月11-15日在英国伦敦举行。
本文第一次完成了对CT Monitor实现和部署的深入了解，揭示了CT Monitor在实践中存在的技术挑战，并讨论了改进建议措施。本文工作由中科院DCS中心联合美国堪萨斯大学李丰君和清华大学李琦等共同完成。
声明：本文来自中科院DCS中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
