时间:2024-05-04
张 婕, 王 伟, 马 迪, 毛 伟
1(中国科学院 计算机网络信息中心, 北京 100190)
2(中国科学院大学, 北京 100049)
3(互联网域名系统北京市工程研究中心, 北京 100190)
4(北龙中网(北京)科技有限责任公司, 北京 100190)
公钥基础设施(Public Key Infrasture, PKI)和 SSL/TLS加密协议是当今互联网进行安全通信的关键要素.研究表明, SSL/TLS协议中的证书安全漏洞大量存在于各种系统中[1].在 TLS PKI中, 作为可信第三方的证书颁发机构 (Certificate Authority, CA)和管理着可信根CA证书列表的信任根源Web浏览器, 在TLS体系中有用重要权威.正因如此, 若CA或浏览器被攻击或恶意劫持, 会造成严重的安全危害.近年来有关攻击事件频发, 结束了盲目信任CA签发证书的时代.例如在 2011 年, 著名认证机构 Diginotar[2]和Comodo[3]遭到黑客入侵, 颁发非法证书;2015 年 4 月,Google在发现中国互联网络信息中心(CNNIC)私自给他人签发证书的行为之后, 决定在包括Chrome在内的所有产品中删除CNNIC根证书, 称不再信任国内CNNIC证书[4];2016年10月, 因国内唯一一家通过国际审计、拥有全球信任的顶级根证书的商业CA沃通及被其秘密收购的StartCom均存在不同程度的违规问题, Google不再信任沃通的证书和StartCom CA[5].在这些情况下, 攻击者可以进行中间人(MitM)攻击[6],拦截安全链接, 并窃取用户的敏感信息.为了减轻SSL证书系统的结构性缺陷, Google于2013年3月提出了 Certificate Transparency(数字证书透明性, 简称CT)技术[7], 用于提升SSL/TLS协议的服务器证书的可信性, 从而提高HTTPS网站的安全性.同年6月,CT技术被推进为IETF标准RFC6962:Certificate Transparency.2014 年 1 月, IETF 成立 Public Notary Transparency(TRANS)工作组, 在其中讨论RFC6962的更新, 包括增加CT的设计和部署经验, 和使用CT时的隐私性考虑.
对于证书颁发机构的实现情况, 2013年3月,Google推出其首个证书透明性日志, 同年9月,DigiCert成为首个实现CT的数字证书认证机构.Google Chrome在2015年开始要求新颁发的扩展验证证书(EV)提供CT证明, 并要求2018年4月之前, 所有SSL证书都要支持CT.
CT是打破原有以证书颁发机构CA为认证体系中心的、扁平式认证体系的带外认证技术.但CT在提升HTTPS网站的安全性的同时, 也改变了传统WEB PKI的信任模型, 引入了新的运行风险.但Google却一直规避CT所带来的安全问题[8], 借助其Chrome浏览器在全球终端用户中的覆盖率, 全球范围内推广部署CT.因此, 为了更好地部署和应用 CT, 对于数字证书透明性的安全威胁因素的研究尤为重要.
然而, 截至目前, 国内外学术界围绕CT展开的研究工作主要是针对证书撤销和分散CA权力的方案实现, 缺少以CT安全威胁因素为主题的综述性文章, 本文致力于填补这个研究方向的空白.本文首先介绍了CT基本原理, 基于基本原理分析归纳总结出基于CT的Web PKI信任模型和安全威胁模型, 从而提出安全保障机制及应用部署建议, 最后展望了未来基于CT的Web PKI的挑战与机遇, 以期对未来研究提供有益的启发和借鉴.
本文剩余部分的组织结构如下:第1节回顾了Web PKI信任模型及结构缺陷, 第2节阐述了CT的基本原理.第3节和第4节分别描述了基于CT的Web PKI信任模型、安全威胁模型.第5节针对CT的运行风险和存在的安全威胁, 提出了部署建议.第6节总结和展望.
近年来, 大量网站默认使用基于SSL/TLS协议的https安全通信.在操作系统/浏览器中, 通常预置了数百个CA的根证书, 每个CA都可以签发任何域名的服务器证书.这就导致了Web PKI系统有很大的缺陷:恶意攻击者只要能成功入侵其中一个CA, 就能够签发它所需要的、包含虚假信息但可验证成功的证书.
以一个真实事件为例, 如图1所示, 恶意攻击者通过DNS缓存污染的方法将用户劫持到一个假冒的gmail.com网站, 并入侵DigiNotar CA为该网站伪造了一张SSL证书;当用户访问假冒网站时, 浏览器会成功验证该虚假证书并建立https连接, 从而获取用户的敏感信息, 也即通常所说的网络钓鱼.有时为了不被用户发现异常, 攻击者还可能会在另一端与真实合法的gmail.com建立连接, 并作为中间人(MITM)窃取用户与合法网站之间的通信数据.
鉴于证书的重要性, 很多机构投入了很多的精力来研究改善证书管理的现状, 以期增强证书的有效性验证.研究人员提出了很多加强SSL安全的方法, 如采用 HTTP Strict Transport Security(HSTS)来遏制SSL 剥离[9];使用 The Public Key Pinning Extension for HTTP (HPKP)允许网站使用HTTP标头指定自己的公钥, 并指示浏览器拒绝具有未知公钥的任何证书[10];采用 DNS-based Authentication of Named Entities(DANE)[11], 依赖与DNSSEC阻止伪造修改DNS记录来使浏览器只接受一些特定的证书;Google提出并发布的数字证书透明性[7], 可以实时检测伪造证书, 出于谷歌的影响力, 这个方案的普及对于保障证书的安全性有显著的改善.
图1 https连接的建立过程 (中间人攻击)
CT的目标是提供一个开放透明的监控和审计系统, 要求CA向该系统中记录所有的证书签发行为, 从而让任何CA和域名所有者确定证书是否被错误签发或被恶意使用, 保护用户访问https网站时的安全.
CT改变了证书的签发流程, 新流程规定:证书必须记录到可公开验证、不可篡改且只能添加内容的日志中, 用户的Web浏览器才会将其视为有效.通过要求将证书记录到这些公开的CT日志中, 任何感兴趣的相关方都可以查看由任何CA向任何网站签发的证书.这能够促使CA在签发证书时更加负责, 从而有助于形成一个更可靠的系统.
CT并不能阻止CA签发错误或虚假证书, 但是它能让人们清楚地看到CA签发的所有证书, 从而使检测这些证书的过程变得相对容易.具体来说, CT有三个主要的功能性目标:(1) CA 难以错发证书, 从源头上减少了错发证书地机率.(2) 提供一个公开的审计和监控系统.(3) 用户能够识别恶意/错误的证书.
如图2所示, CT系统由三部分组成, 确保CA和日志服务器遵循CT工作流程:
(1) 证书Log日志:维护可公开审计、只增不减的证书日志.
(2) 监控器:通过下载并检查所有日志条目来检查日志中的可以证书.
(3) 审计器:根据日志的部分视图验证日志的行为是否正确.
图2 CT系统组成部分
基于CT的Web PKI信任模型分为带内带外两部分机制, 如图3所示.其中带内信任机制是基于传统Web-PKI信任模型的, 证书颁发者(CA)是信任锚点,而Web浏览器是负责验证证书的可信依赖方.带外信任机制是基于CT的验证链路, 在此情况下, 依赖方不仅要信任传统Web PKI, 还要信任CT机制中的log日志.通过带内带外两种信任机制, 为整个SSL证书系统增加公共监督和审查功能来增强信任链模型.
在传统Web-PKI信任模型中, 如图4所示, 浏览器预置了一组受信任的根证书.可信的证书列表由浏览器供应商初始化、更新、在TLS连接建立期间, 目标网站提供相应域名的端点证书, 以及中间证书(一个或多个), 旨在让浏览器构建从根到端点的证书信任链.在这种情况下, 证书颁发者(CA)是信任锚点, 而Web浏览器是负责验证证书的可信依赖方[12].根据X.5905标准, 公钥需要通过数字证书绑定身份, 则依赖方可以确定Web服务器的真实性[13].
Web PKI使用CA层次结构模型, 具体信任关系为:如果证书由浏览器信任的CA签发, 则采用该证书的浏览器是可信的.Web PKI有一组根CA, 它们的公钥通常存储或预配置在根CA的受信任列表中、操作系统和浏览器中.根CA作为整个Web PKI的基础, 证书路径是指从根CA证书到Web服务器证书的证书链.链路验证是指验证路径的正确性和有效性.
图3 基于CT的Web PKI信任模型
对于依赖方浏览器来说, 为了确定公钥的合法性,信任关系通过以下两个操作进行确认:
(1)首先, 依赖方必须信任CA给签发证书的秘钥是合法的(秘钥合法性).
(2)其次, 依赖方必须信任CA颁发合法证书(颁发者信任).
图4 基于传统Web PKI的带内信任模型
在Web PKI中, 信任模型是颁发者信任和秘钥合法性二元信任.由信任的根CA颁发的证书都是可信的, 但不同的CA可能实行不同的信任方案, 采用不同的安全机制.
但是, CA 可以任意颁发证书, 这使得Web PKI信任模型也存在中间人攻击的问题:任何一个CA可以为任何一个网站签发证书, 无需该网站的同意.拿到这种非授权的证书, 可以构造一个假冒的网站, 用户的浏览器在访问这种服务器时不会产生警告, 从而攻击者可以进行中间人攻击.
CT改变了传统的Web-PKI信任模型, 除了要信任传统的Web-PKI模型, 即带内信任机制CT, 还要信任 Log, Log 会对信任产生干预, 即带外信任机制.基于CT的Web PKI信任模型中的带外信任机制主要由三个实体组成:
A.证书日志 Log:存储终端证书
B.证书监控器 Monitor:监控信任锚点
C.证书审计器 Auditor:浏览器验证证书
如图5所示, 基于CT的Web-PKI数据传输模型原理简述如下:
CA在签发了某个Web服务器的证书之后, 及时地将该证书签发行为记录到公开的Log服务器上.Log服务器以Merkle Tree[14]的形式来存储SSL证书,保持 Append-Only(只增不删)特性.即, 一旦 Log 接受了某个证书, 该Log的属性即可保证相应条目永远不会被移除或修改.
图5 带外信任模型原理
更具体地说, CA向Log服务器发送一个预签证书(pre-certificate), Log服务器使用自己的私钥签署一个证书签署时间戳 (Signed Certificate Timestamp, 简称SCT), 并返回给CA, 随后CA将SCT嵌入到正式的SSL证书中, 并发送给Web服务器.Web服务器随后在TLS握手协议中将带有SCT签名的证书发送给Web浏览器.
域名管理者、CA和利益第三方都可以部署CT Monitor.域名管理者通过CTMonitor, 周期性的对Log进行监视, 可以实时得知自己的各个域名被(部署了CT的所有CA)签发的证书, 并从中排查出可疑证书.而CA也可以通过CT Monitor监视自己或其他CA签发的证书.从而CA或域名管理者可以防止错误证书(如伪造的服务器证书或未得到合法授权的中间证书)被他人滥用.
Auditor使用证书上附带的SCT签名来向Log服务器验证该证书是否被记录, 如果没有,Web浏览器就可以拒绝访问该证书所对应的网站, 以保护自己的安全;另一方面, Auditor可以通过CT的 gossip 协议[15]将该问题证书的信息通知给Monitor.以便CA或域名管理者及时处理.
此外, 证书透明性中的Gossip协议[16]作为其通信协议, 允许Monitor、Auditor、Web客户端之间相互交流信息, 共享从Log服务器中获得的证书信息, 以保证证书的一致性、检测Log服务器的不正当行为.
从3.1和3.2节分析可以看出, 浏览器(依赖方RP)在基于CT的Web-PKI体系中是关键信任对象,是连接传统信任模型和CT Log服务器的桥梁, 也是信任的核心.它是带内带外两条数据验证的信任核心:
(1) 带内数据验证:
作为证书依赖方, SSL/TLS协议客户端(通常是浏览器)预先存储有自己所信任的根CA自签名证书, 用来验证与之通信的PKI用户的证书链, 可信地获得该用户的公钥, 从而用于机密性、数据完整性、身份鉴别等各种安全功能.浏览器选择哪些全球公开的信任锚点根证书, 也决定了后续有哪些CA是可信的.
(2) 带外数据验证:
由于CT机制的部署, 浏览器只接受放入Log服务器并由其信任背书的证书, 预示着浏览器在信任带内数据验证起点之前首先需要信任Log服务器的公钥.
综合这两个数据验证路径, 浏览器直接影响基于CT的Web-PKI系统中证书条目的有效性.依赖方RP和Auditor分别是带内数据验证和带外数据验证的核心, 由此可见, 部署CT以后的整个Web-PKI体系信任核心是浏览器.
数字证书透明性(CT)这一概念及其相关技术体系, 是一次针对Web PKI安全缺陷在协议层面所做的系统性修复工作.这一安全技术扩展, 改变了传统Web PKI的威胁模型, 但也引入了新的运行风险.本节面向CT体系中的实体对象(CA、证书、日志、监视器、浏览器等), 分析了“证书错误发放”错误类型和威胁因素, 提出了基于CT的Web PKI的安全威胁模型.
IETF 草案“Attack Model for Certificate Transprency”[17]讨论了CT在Web PKI背景环境中的威胁、潜在攻击场景.现将草案中提到的威胁情况根据CT中的实体进行提炼概括为安全威胁模型, 如图6所示.
图6 基于CT的Web PKI安全威胁模型
请注意, CT中的实体(Log服务器、Monitor、CA、Web客户端), 可能存在两种情况:一种是实体本身为恶意“攻击者”, 产生一系列的威胁因素;另一种可能性是, 实体是非恶意的, 由于操作错误或受到攻击的情况下, 产生一系列威胁因素.
在本模型中, 可以将威胁因素如下归类:
1) (a3, a5, b4, b5 和 c2)这几类威胁涉及证书的有效性和语义验证.
2) 从密码学角度分析, 主要存在的威胁是(a2和b3), 涉及的实体主要是 Monitor和 Auditor.(通常不会将Monitor和Auditor分开讨论, 因为两者可以通过Gossip协议共同协作验证日志行为)
3) (c1和d1)类为无法根除的带外威胁, 因为无法强制CA将证书添加到日志中, 也不能强迫客户端拒绝特定的证书.但是如果客户端拒绝缺少SCT的证书,那么违反c1类威胁的提交者会发现客户端拒绝了他们的证书.
CT通过将证书添加日志, 从而达到公开审计的目的, 但若日志服务器是恶意的, 可能采取多种恶意行为.具体如下:
日志可能假意阻止虚假证书的日志条目, 或者可以为虚假证书创建证书的条目, 但不报告其虚假性.还可能会为虚假证书签署用于验证有效性的证书时间戳SCT, 从而虚假证书会被视为有效.
此外, 如果行为不当的日志可能会向实体呈现不同的Log日志视图, 以帮助隐藏目标用户的虚假证书.日志不会执行句法或语义检查, 或者简单地不发送错误报告.这种情况, 我们无法通过CT机制审计证书.
另一种情况是, 恶意日志可能会把语法有效的证书报告成语法错误.这可能导致CA进行不必要的调查工作, 或者可能不正确地撤销并重新颁发证书.
监控器监控日志中的可疑证书, 以发现非法或未经授权的证书、证书异常扩展或具有非法权限的证书.监控器只要检测到异常情况, 就会通知用户.
若监视器是恶意的, 将不会执行句法或语义检查,或者简单地不发送错误报告.还可能会把语法有效的证书报告成语法错误, 这可能导致CA进行不必要的调查工作, 或者可能不正确地撤销并重新颁发证书.
更严重的是, 行为不正确的Monitor不会告知目标主体证书是虚假的, 甚至向目标域名所有者发出虚假警告.
在基于CT的Web PKI体系中, CA的权力虽然被Log Server、证书持有者分散, 但是仍存在安全隐患.
CA若其选择不将证书添加到日志中, 从而屏蔽CT的监控作用;若颁发虚假证书则可以伪装成经过公开审计的有效证书;CA可能会拒绝撤销或拖延证书撤销的时间, 从而允许虚假证书仍存在一段时间, 从而引发安全隐患.
另一种情况, 恶意CA可能会反其道行之赢得信任:通过撤销虚假的证书, 或列出虚假证书黑名单, 以避免浏览器厂商对CA采取惩罚措施.
更严重的是, 若多个父级CA为恶意的中间CA签发证书, 则恶意证书存在多个有效路径验证链, 即使其中一条链路验证被破坏, 其他链路验证有效, 如图7所
图7 虚假证书的多个证书链
在CT架构中, 必须对证书进行日志记录, 以使监视器能够检测到证书错发, 并触发后续撤销.若浏览器拒绝没有SCT的证书、认为其无效, CA为了使其颁发的证书有效, 会主动将其添加Log服务器, 进行日志记录, 以获得 SCT.然而, 并不能强制浏览器拒绝缺少SCT证书, 因此这也是一种威胁因素.
CT技术开始在Chrome和Chromium中广泛部署后, 也引起了学术界的高度关注和后续研究.文献[18,19]完成了对证书撤销操作的公开审计, 使得能在Log服务器上维护可审计的证书撤销状态信息.PoliCert[20]方案和ARPKI[21]方案进一步限制了CA在SSL/TLS服务器证书签发过程中的权力.文献[14]和[22]提出了更有效的Gossip协议, 确保CT用户获得的日志具有一致性, 也在Gossip协议中更加注重隐私保护.文献[15]改进了CT技术使其具有扩展功能和短日志证明(Proof)格式.
通过上述文献分析, 对于CT技术方面的安全保障机制, 可以归结为以下两点:
(1)TLS PKI基础架构中CA拥有很大权利, 域所有者无法控制其证书的使用和验证.CT及其扩展增强方案, 都是在证书签发阶段, 由Log服务器、证书持有者借入来分散部分权利.然而, 由于CT的目标仅仅是使证书公开审计, 但是攻击者仍可以入侵CA完成虚假证书的审计过程.所以我们需要新的技术模型实现对CA权力进行限制的可信模型.
(2)另外, CT本身并没有对证书撤销进行改进, 所以技术方面需要改进证书撤销机制, 实现对证书撤销操作的公开审计.证书撤销也必须能够验证一致性, 并且允许删除以及添加撤销状态.证书撤销还必须能够有效地验证条目是否存在于日志的特定的版本中.
针对数字证书透明性的安全威胁问题, 本文首先梳理了基于CT的WEB-PKI的信任模型, 分析了信任模型的信任核心, 针对信任核心以及CT技术的其他实体对象归纳总结出安全威胁模型, 并提出了技术上的ji简易部署.
在Web PKI体系中, 认证机构CA给予的信任水平一直在下降, 基于日志方法的CT能够确保对TLS欺诈证书公开审计.但针对本文安全威胁模型, 如何对于CT技术中Log服务器、Auditor、Monitor等实体的不当行为进行检测和传播是目前基于日志的PKI体系结构的缺失;并且对于CT传播过程中存在的隐私问题, 效率和可部署性都是具有挑战的研究方向.近2年来, CT技术在走向大面积推广的过程中, 其技术研究出现了新的深度.我们有理由相信作为普适性的证书验证技术CT必定会有更加丰硕的研究成果.CT技术的安全性部署、隐私性、对Log服务器的检测等工作将会在未来有更进一步的深入探讨和研究.
我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!