证书透明化(Certificate Transparency)介绍

标签:无 2228人阅读 评论(0)

证书透明化(Certificate Transparency)介绍

1. 背景

Web PKI 体系中站点身份认证是通过证书信任链验证完成的。通信过程中, 证书依赖方(Relying Party)获得通信对方的证书链, 根据自身配置存储的根 CA 逐一验证证书链中各数字证书, 获得通信对方的公钥,保证通信的安全性。数字证书由 证书认证机构(Certificate Authority,CA)签发管理,为双方安全通信提供电子认证。CA 作为受信任的第三方,承担公钥体系中证书合法性验证的责任。

1587204238709082821.png

通常情况下,客户端能够检测出伪造的数字证书,但对 CA 自身问题误颁发的证书无能为力。由于 PKI 的体系模式下用户默认信任 CA, CA 签发的非法证书,能够通过证书信任链验证,难以被客户端发现。且即便被识别,依赖现有机制也难以快速消除影响。随着 CA 数目逐渐增加,CA 自身的安全已成为当前体系中的一个脆弱点,任一 CA 被攻破都可能颠覆全球安全通信。CA 签发非法证书案例如

  • 2011年荷兰 CA DigiNotar 被黑客入侵,黑客给 google.com 在内的 531个网站发行了伪造的 CA 证书。调查证实,DigiNotar 的所有八台证书服务器均遭入侵。伊朗用户在伊朗发现大量伪造的 *.google.com 证书,伊朗政府被怀疑利用伪造但有效的 CA 证书对伊朗 Gmail 用户发动中间人攻击。这一事件导致 DigiNotar 公司的根 CA 证书被主流浏览器或操作系统厂商删除,最终彻底破产。
  • 2015年9-10月,Google 发现赛门铁克旗下 Root CA 未经同意签发了众多域名的数千个证书,其中包括Google 旗下的域名和不存在的域名。谷歌宣布逐步降低对赛门铁克证书的信任。

此外,域名所有者管理不善也可能导致域名被攻击者控制,攻击者可能仿冒域名所有者身份向 CA 申请证书。这种情况依赖现有证书信任链校验机制同样难以发现。 证书透明化(Certificate Transparency,CT)[RFC 6962] 旨在解决这些问题,它是 Google 提出的用于监控/审计 SSL 证书的一个开源框架,虽然不能阻止 CA 误签发证书,但域名持有者可以通过证书透明度来监视其域内证书颁发的情况来判断证书是否被错误签发,大大提升了 Web PKI 系统的知情度和透明度。

证书透明化旨在实现以下三个目标:

  • (1)避免(或增加难度) CA 在域名持有者不知情的情况下签发证书。证书签发会保留记录,给 CA 自身的监管机制增加压力。
  • (2)提供公开的审计和监视系统,使域名持有者/CA 能够判断证书颁发过程是否存在不当/恶意颁发行为。域名所有者能够通过监控自己域名及时获得警报。如果发现 Log Server上有其他证书与自己的域名相同,能够快速做出反应。
  • (3)尽可能保护用户免遭不当/恶意颁发证书的危害。客户端(如浏览器)验证证书是否在 CT Log Server 中记录,如果没有记录则给用户安全警告,迫使恶意网站不得不提交证书到 Log Server上规避浏览器的安全检查。

2. 工作原理

2.1 基本组件

证书透明化框架包括三个组件:证书日志(Certificate Logs)、证书监控(Certificate Monitors)和证书审计(Certificate Auditors)。

证书日志

证书日志维护加密保证的、公开可审计的证书记录(仅追加)。任何人都可以向日志提交证书。同样,也都可以查询日志以获得证明(日志是否正常运行,或某个特定证书是否已被记录,等等)。日志服务器可由 CA、ISP 或任何其他相关方独立操作。

证书监控

证书监控设备定期访问所有日志服务器并监视可疑证书。例如,监控器可以判断某个域是否被签发了不合法或未经授权的证书,并且可以监视异常的证书扩展名或特殊权限的证书(例如CA 中间证书)。监视器的作用与征信告警相似,它能够告知用户何时被攻击者仿冒身份申请贷款或信用卡。

证书监控通常由公司等组织运行,如 Google、银行或政府。其他机构提供的监控服务或作为收费订阅服务运行。

证书审计

证书审计是轻量级软件组件,通常执行两个功能,

  • 首先,它们可以验证日志的行为是否正确,前后行为是否保持一致性。如果证书日志行为异常,那么该日志服务需要自解释,否则存在被关闭的风险。

  • 其次,它们可以验证特定证书是否出现在日志中。这是一个重要的审计功能,因为证书透明框架要求所有SSL证书都要注册到日志中。如果证书没有在日志中注册,该证书可能是可疑的,TLS客户端可拒绝连接到具有可疑证书的站点。

证书审计可以是浏览器 TLS 客户端的组成部分、独立的服务或证书监视的子功能组件。大部分证书审计可能运行在CA,这是确认所有 CAs 操作完整性的有效方法。

这些组件共同组成了一个开放框架,任何人都可以近实时地监控和验证新发布的和现有的 SSL 证书。

2.2 运行机制

2.2.1 证书日志功能

证书日志是证书透明框架的中心,有以下三个重要特性:

  • (1)只能追加(append-only):证书只能被添加到日志中,已有的记录不能被删除,修改或插入。
  • (2)加密保证(cryptographically assured):日志使用 Merkle Tree Hashes 加密机制来防止篡改等违规行为。
  • (3)公开审核(public auditable):任何人都能查询并验证证书日志,保证证书被正确添加到日志中。

证书日志使用 Merkle Tree Hash 来验证日志完整。证书日志服务器公布它对应的 URL 和公钥,用户可以通过 HTTPS GETPOST 方法交互。GoogleApple 有各自的信任 Log 申请政策标准。

2.2.2 日志基本操作

用户向证书日志组件提交有效证书时,日志返回 签名证书时间戳(Signed Certificate Timestamp,SCT),它伴随证书整个有效使用期。GoogleApple 都要求证书至少提交到两个不同的 CT log(Google 规定其中还必须包含一个由 Google 自身运行维护的 log)。CT 支持三种交付带有SCT的证书方法。

X.509v3 扩展

证书签发机构(CA)使用 X.509v3 扩展字段记录 SCT。下图为工作流程,

  • (1)CA 向证书日志提交预认证;
  • (2)日志返回 SCT;
  • (3)CA 将SCT作为 X.509v3 扩展附加到预认证中,对证书签名,然后将证书交付申请者。

ct_ssl_issuance_1.png

这种方法不需要服务器更改工作流程,用户可以像以往一样管理其 SSL 证书。Let's Encrypt 签发给 mesalab 的证书所采用了这种方式,下图为证书拓展项中的两条 SCT 记录。

1587204329531080053.png

TLS扩展

服务器可以使用特殊的 TLS 扩展交付SCT。这种情况下,CA 签发证书给申请者,证书申请者自行将证书提交到日志中,日志返回对应的 SCT。在 TLS 握手期间,服务器使用带有 SCT 拓展的 TLS 字段发送给客户端。

ct_ssl_issuance_2.png

这种方法不改变 CA 颁发SSL证书的方式,但需要服务器修改配置适配 TLS 扩展。

OCSP Stapling

CA 按照普通流程签发证书后,将证书提交到 CT Logs 服务器得到 SCT,然后通过在线证书协议(Online Certificate Status Protocol,OCSP),将 SCT 封装到 OCSP 响应中。服务器可通过发起 OCSP query 获得 SCT.

2.2.3 监控和审计的基本操作

证书监控通常运行在证书签发机构(如 CA)或证书所有者一侧。监控日志中的可疑证书,如非法或未授权的证书,异常的证书扩展等;同时确保所有签发的证书在日志中可见。

证书审计包括验证日志的整体完整性,日志中是否有特定的证书等操作。证书审计功能通常包含在证书监控中。TLS 客户端在通信中只需验证 SCT 签名的有效性即可。

公开提供查询的证书监控服务:

  • Google:未公开API。
  • facebook:Facebook Graph API,支持用户订阅特定域名。
  • SSLMateHTTP GET/POST API,收费 & 查询数目限制。
  • Entrust Datacard:未公开 API。
  • crt.shSql interface.
  • Censyspython API,收费 & 查询数目限制。

3. 相关测量工作

3.1 A First Look at the CT Landscape: Certificate Transparency Logs in Practice,PAM’ 17

Main Contributions:测量 CT logs 中记录的证书的特征;日志在实现过程中的属性设置差异;以及实际网络中证书日志的使用情况。

Datasets:主动获取公开 log server 的证书日志(截至 2015.12 Chrome 使用的 10 个证书日志记录提供方和1个其他类型),被动收集大学一周的流量数据(包括 232 million HTTPS 会话,552 million 证书转发,67644 个不重复证书)。

Results

  • 不同机构/组织提供的证书日志服务属性(接受的根CA数目,MMD,UI,TTP值)存在差异。以接受的 CA 数目为例,Google 日志可接受的 CA 数目最多(474/503,包含大多数可观测根),其他 CA 机构运行的日志接受的数目较少(CA 通常更愿意记录自己颁发的证书,而非其他 CA 颁发的证书。)。
  • CT logs 可以作为一个监控分析新签发证书的有效工具,大规模日志服务器记录超过5million。不同日志中存储的证书类型(DV/EV/OV)占比差异较大,其中还发现了部分弱密钥/签名证书。
  • 至少 80% 的证书在多个日志中重复记录(Cross-Log Publication).
  • 通过与被动测量的数据比对,大型的受欢迎程度高的域名(如 google.com, apple.com, facebook.com 等)对应的证书日志量也更高,CA 维护的日志对非流行域名的覆盖很少。

3.2 In Log We Trust: Revealing Poor Security Practices with Certificate Transparency Logs and Internet Measurements,PAM’ 18

Main Contributions:主动扫描 196M 主机节点,访问 CT logs 证书日志获取并分析证书数据;被动收集两个测量点的 DNS 流量,分析证书日志情况。

Datasets:采用获取 CT logs,发起主动 HTTPS 扫描,获取 CRL 文件,被动 DNS 捕获四种方式收集证书数据,数据概况如下表所示。

1587204395554060964.png

Results

  • 测量的5家 CA 签发的证书都存在不同程度上违反证书基本要求(Baseline Requirements)的行为。
    • 作者将此类行为划分为四类,身份标识(SAN/CN 字段),签名(hash 算法),密钥(加密算法或长度)和验证时间)。
    • 随时间推移整体情况有大幅缓解,不安全证书比例整体下降。
  • CT 日志中保存证书与主动扫描证书对比如下表,CT 日志包含证书安全性高,容易被浏览器验证通过。

PAM18-2.png

  • 非 HTTPS 证书(如 SMTPS, IMAPS, POP3S, FTPS, XMPPS, IRCS)在证书日志中比例较低(约3.5%以下)。
  • CT 安全模型中要求的 gossiping 协议未在实际部署中广泛应用。

3.3 The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem,IMC’ 18

Main Contributions:从 5个不同方面介绍了 CT 的部署情况以及相关的安全和隐私影响。

Datasets:CT Logs;被动采集 UC Berkeley 一年的流量(26.5G TLS 连接),主动扫描得到的 423M 域名证书。

Methodology & Results

  • CT 日志数据分析:证书量签发排行 top5 CA 签发证书占日志 99%。各 CA 选择提交的日志服务器分布严重不均衡。

  • CT 部署情况

    • 被动测量的流量数据中有 8.6G(32.61%)的连接至少包含一个 SCT。5.7G(21.40%)证书拓展中包含至少一个SCT,3G(11.21%)TLS 扩展中包含至少一个 SCT,2M(>0.01%)在OCSP响应中包含至少一个SCT。下表所示是观测到的 top 15 CT Logs.
    • 主动扫描得到的4280万个证书中,有 2950万个(68.7%)包含一个SCT。和被动测量的 CT Logs 排行有所不同,74% 的证书 SCT 由 Cloudflare Nimbus2018 log 发布,71%来自 Google Icarus log。这表明,用户在实际使用中的证书与网络中提供的证书分布情况存在较大差异。

1587204468004060514.png

  • 域名信息泄露:CT 日志存在泄露子域名的风险。作者使用CT 日志 FQDN 重新构造新的 FQDN,使用 massdns 验证,210.7M 新构造的 FQDN 中发现有 18.8M 返回对应地址记录,即隐蔽的子域名。
  • 钓鱼网站检测:CT 日志记录的域名数据集能为识别检测钓鱼网站提供新方案。
  • CT 蜜罐:搭建 CT 蜜罐,进一步测试 CT Monitor 和恶意攻击者的行为。作者生成12字符长的随机子域名,构造A/AAAA 记录,通过监测权威域名服务器的解析记录及服务器的访问记录监控子域名访问行为。
    • 创建证书记录后,CT Monitor 能够在数分钟至数小时内发起查询响应。
    • 攻击者可能利用 CT Logs,易于发现新域名。

3.4 Does Certificate Transparency Break the Web? Measuring Adoption and Error Rate,IEEE S&P’19

Main Contributions:分析 CT 的部署情况,通过 Google Chrome 测量错误率,讨论 CT 部署的挑战。

Methodology & Datasets

  • A. Chrome Usage Metrics:通过分析 chrome 用户使用数据统计 CT 应用率 & 错误率。
  • B. Chrome 证书错误报告:通过 chrome telemetry 系统收集证书错误信息。
  • C. 服务器支持程度:Google 的网络爬虫获取的证书 SCT 记录。
  • D. CT logs 记录。
  • E. Chrome 帮助论坛。

Results

  • Chrome 中,71% 的 HTTPS 请求已支持CT,99.7% 支持 CT 的 HTTPS 是符合要求的。
  • 对合规的 CT 分析:
    • 在 chrome 的证书错误警告中,用户忽视违反 CT 策略警告是其他类型证书警告的 2 倍。
    • Google support 中 60% 关于 CT 警告处理的讨论议题解决方法有误/不当。
    • CT 造成的网络不可达事故非常少,Google 努力促进 CT 稳定向前推动。

1587204502556018526.png

  • 开放性问题 & 部署挑战
    • 需要多方(浏览器厂商、CAs)合力推动,持续渐进部署。
    • CT 定义了用于审计/验证日志行为的协议,并未广泛应用。
    • 提交到日志的证书增加了部分域名的暴露风险。
    • 用户选择性忽视关于 CT 的错误问题警告。

3.5 Certificate Transparency in the Wild: Exploring the Reliability of Monitors,CCS’19

Main Contributions:CT Monitor 若不能返回监控域名的所有证书,CT 框架的可靠性则会大大降低。作者从CT Monitor 可靠性角度对 PKI 证书透明化应用现状进行了系统深入的研究。

Results

  • Q1:谁可以做 CT Monitor?

    • 对2018年近一年的 CT 数据分析,Internet 共部署 80多个 CT Logs,认可的 CA 约700多个,记录的证书数量已超过28.7亿个。证书增长700万+/天,43.99GB/天,带宽 5Mbps。作为Monitor所需具备的能力(存储、计算、网络带宽)远远超出普通域名所有者的承受能力。
  • Q2:第三方 CT Monitor 是否可靠?
    • 多数 Monitor 可以在证书提交给日志的8个小时内查询到,Facebook存在较大延迟。
    • 没有任何一个第三方Monitor可以保证返回公共日志中记录的所查询域名完整的有效证书集合。
  • Monitor 查询不完整原因分析:
    • 处理延迟:crt.sh,SSLMate(数据积压),Censys(延迟一两天)。
    • 预证书处理存在问题:Google(Alex Top-1K域名中缺失的76.9%为预证书)。
    • 未及时恢复的事故:Censys(特定时间窗口,数据中心转移),Google(特定时间窗口,原因未知)。
    • 不支持的域名:SSLMate(特定顶级域名),Google(未知),Facebook(无效或未查询到)。
    • API查询返回上限:Censys (25000),Facebook (5000),SSLMate (超时未返回)。
  • 可能的解决方案:

    • monitor 服务可靠性审计:类似数据库系统的黑盒测试。

    • 资源按需分配,启用 monitoring as a service (MaaS).

4. 其他 PKI 安全增强方案对比

除 CT 外,其他 PKI 安全增强方案可归纳为以下两类:

  • 客户端增强信任策略:客户端记录首次/上次访问时获取的数字证书,比对一致性。

    • HTTPS Public-Key-Pinning(HPKP)[RFC 7469]:站点通过 HTTPs 头部向浏览器声明网站绑定的证书公钥信息。

    • Trust Assertions for Certificate Keys(TACK):站点发起 server hello 时包含 Tack_Extension 字段,声明绑定的证书公钥信息。

  • 证书主体发布限定策略:证书所有者对证书的安全使用规则做定义和声明。
    • DNS-Based Authentication of Named Entities(DANE)[RFC 6698]:TLS client 请求域名的 DNS TLSA 记录,确保与 HTTPs 获得的证书匹配。
    • DNS Certification Authority Authorization(CAA)[RFC 6844]:证书所有者限定该域名下证书可以由哪些 CA 签发。

Certificate Transparency 给出的不同方案特性对比表:

1587204593092034816.png

其中:

  • NSC(No side-channels,无需额外通道):实验表明,SSL 握手期间,向第三方发送的额外请求失败的几率至少为1%,失败的概率具体取决于使用协议(通常 > 1%)。
  • IR(Instant recovery from loss of key,密钥丢失恢复):如果服务器丢失了私钥,是否可以立即发布使用新证书?
  • GA(Detects Global Attack,全局攻击检测):是否能够识别出全局大范围攻击?
  • TA (Detects targeted attack,局部攻击检测):是否能识别局部范围攻击(如 MITM)?
  • NTTP(No trusted third parties,无额外信任方):是否避免引入额外信任方?
  • IS(Instant startup,快速恢复):服务器能否立刻使用新签发的证书?
  • US(Unmodified Servers,兼容性):服务器是否可以不做适配而直接使用?

参考文献

[1] https://www.certificate-transparency.org.

[2] https://imququ.com/post/certificate-transparency.html.

[3] 王琼霄, 王聪丽, 林璟锵, and 宋利. “PKI证书服务的安全增强技术.” 信息安全研究 5, no. 01 (2019): 50–58.

查看评论

暂无评论

发表评论
  • 评论内容:
      
首页
团队介绍
发展历史
组织结构
MESA大事记
新闻中心
通知
组内动态
科研成果
专利
论文
项目
获奖
软著
人才培养
MESA毕业生
MESA在读生
MESA员工
招贤纳士
走进MESA
学长分享
招聘通知
招生宣传
知识库
文章
地址:北京市朝阳区华严北里甲22号楼五层 | 邮编:100029
邮箱:nelist@iie.ac.cn
京ICP备15019404号-1