代理网站安全性

第3卷第2期信息安全学报Vol.
3No.
22018年3月JournalofCyberSecurityMarch,2018通讯作者:蔡权伟,博士,助理研究员,Email:caiquanwei@iie.
ac.
cn.
本课题得到973课题《租户可控的云数据安全理论与方法研究》资助.
收稿日期:2017-10-17;修改日期:2017-12-07;定稿日期:2018-02-05面向HTTPS的内容分发网络代理关系透明化王泽1,2,3,李文强1,2,3,蔡权伟1,2*1中国科学院信息工程研究所北京中国1000932中国科学院数据与通信保护研究教育中心北京中国1000933中国科学院大学网络空间安全学院北京中国100049摘要内容分发网络可以提高浏览器访问网站的速度和网站安全性(例如防DDoS攻击),已被广泛部署和应用.
当浏览器的HTTPS连接被重定向到内容分发网络的代理服务器时,由于浏览器要求收到的证书与访问的网站域名匹配,内容分发网络不能直接使用自己的证书,而是需要使用内容来源网站的有效证书和私钥,才能正确地同浏览器建立HTTPS连接.
现在,大量内容分发网络和源网站共用私钥,违背了PKI的设计原则.
同时,现有模式下的代理关系对于浏览器是不透明的,内容源网站也无法快速地撤销代理关系.
本文提出了一种面向HTTPS的,公开可验证的内容分发网络代理关系管理方案.
在本方案中,内容来源网站在公开的日志服务器中发布授权代理其内容的内容分发网络的信息,并产生可验证的代理证据.
浏览器使用HTTPS连接内容分发网络代理服务器时,代理服务器推送自己的证书和相应的代理证据.
浏览器不必与源网站直接通信,即可验证代理证据,并使用内容分发网络的证书正确地建立HTTPS连接.
同时,本方案允许内容分发网络和内容来源网站独立地管理各自的私钥,且内容来源网站可以独立地更新、撤销代理关系.
我们实现了本方案的原型系统,并进行了性能评估:实验结果表明,本方案在带宽/延迟/存储等各方面均未造成过大开销.
关键词公钥基础设施;内容分发网络;安全套接层;安全传输层协议;公开日志;代理;信任中图法分类号TN393.
08DOI号10.
19363/j.
cnki.
cn10-1380/tn.
2018.
03.
02DelegationTransparencyforHTTPSwithCDNsWANGZe1,2,3,LIWenqiang1,2,3,CAIQuanwei1,2*1InstituteofInformationEngineering,ChineseAcademyofSciences,Beijing100093,China2DataAssuranceandCommunicationsSecurityCenter,ChineseAcademyofSciences,Beijing100093,China3SchoolofCyberSecurity,UniversityofChineseAcademyofSciences,Beijing100049,ChinaAbstractCDNs(ContentDeliveryNetworks)havebeenwidelydeployedtoachievefastcontentaccessandbettersecuritysuchasDDoSattackmitigation.
However,tosupportHTTPSservices,CDNprovidersneedtheircustomoriginalwebsitestosharecertificatesandprivatekeystoestablishHTTPSconnectionswithbrowsers,becausebrowsersrequirevalidatingthevisitedwebsite'scertificateratherthantheconnectedCDN'scertificate.
SharingprivatekeysexplicitlyconflictsthedesignprincipleofPKIandarisesdeepconcernsoverCDN'sroleinstandardPKItrustmodel,consideringthatthedele-gationbetweentheCDNsandtheoriginalwebsitesisopaqueandtheoriginalwebsiteslackthecapabilityofrapidupdat-ingandrevokingsuchdelegation.
WepresentDET(DelegationTransparencyforHTTPSwithCDNs),asystemthatpro-videspublicandverifiabledelegationmanagementforHTTPSwithCDNs.
InDET,anoriginalwebsitepublishesallitsdelegatedCDNprovidersinapubliclog,andgeneratesacorrespondingdelegationproof,whichisdeliveredtothevisitingbrowseralongwiththeCDN'scertificateduringHTTPSestablishment.
ThevisitingbrowserisabletoverifytheproofandaccepttheCDN'scertificatewithoutanypreviousconnectionstotheoriginalwebsite.
InDET,theoriginalwebsitesandCDNsmanagetheirSSLprivatekeyseparately,meanwhiletheoriginalwebsitesareabletorevokeorupdatetheirdelega-tionindependently.
WehaveimplementedtheprototypeofDET.
Theperformanceevaluationdemonstratesthattheintro-ducedoverhead(intermsofbandwidth,latencyandstorage)ismodest.
Keywordspublickeyinfrastructure,contentdeliverynetwork,SSL,TLS,publiclog,delegation,trust王泽等:面向HTTPS的内容分发网络代理关系透明化171引言内容分发网络(ContentDeliveryNetwork,CDN)是当前广泛应用的网络基础服务,可以为其客户(内容的来源网站,以下简称源网站)提供快速、可伸缩的用户访问和更好的安全保障.
CDN在广泛的地理范围内部署大量的代理服务器,并在代理服务器中缓存源网站的内容供浏览器快速访问.
由此,CDN缩短了浏览器到服务器的传输距离,并分散了源网站服务器的流量压力.
同时,CDN也提供多种安全增强服务,如应用层防火墙、HTTPDNS和DDoS防范.
研究[1-3]表明,近年来CDN市场规模的年均增速在40%以上.
到2019年,预计超过50%的网络流量将通过CDN加速.
当浏览器通过HTTPS访问源网站时,访问的连接可能会被重定向到附近的CDN代理服务器,而不是源网站的服务器.
浏览器会验证收到的证书是否和访问的源网站的域名匹配.
此时,如果代理服务器直接应用CDN自身的证书,会使浏览器验证证书失败.
CDN只有提供源网站的证书并使用对应的私钥才能同浏览器成功地建立HTTPS连接.
因此,目前主流CDN以和源网站共用证书私钥的方式提供HTTPS服务.
现有的共用私钥的方式主要有两种[4,5]:1.
CDN直接使用"客户证书",即由源网站向CDN提供有效证书和对应的私钥;2.
CDN使用"共享证书",此时CDN向自己的CA申请证书,并将源网站的域名添加到主体可替换名称(SubjectAlternativeName)证书扩展中.
在这两种方法中,CDN都拥有了源网站的有效证书和对应的私钥.
共用私钥的方案存在以下严重问题:1)源网站私钥易泄露.
CDN拥有大量源网站的私钥,并需要将源网站私钥部署在大量代理服务器中.
一旦其中一个代理服务器被攻破,该代理服务器中存储的源网站私钥均会泄露.
这导致CDN难以在安全性要求高的网站中(如银行)进行应用.
2)源网站无法独立、即时地撤销代理关系.
目前代理关系是由共用私钥体现的,撤销代理关系需要源网站向自己的或者CDN的CA申请撤销相应的证书.
由于源网站多使用较为昂贵的企业型证书(OrganizationValidationSSLCertificate,OV)或增强型证书(ExtendedValidationSSLCertificate,EV),证书撤销和重新签发会引入额外的经济开销,并导致代理关系撤销不及时[2].
3)代理关系对浏览器不透明.
访问源网站的浏览器无法确定内容的来源是CDN代理服务器还是源网站的服务器,也无法验证代理关系的有效性.
本质上,这是因为传统的SSL/TLS协议将端对端的身份认证和内容的机密性、完整性保护紧密耦合;而HTTPS连接中CDN仅仅是源网站内容的镜像,并非身份的镜像,二者存在着矛盾.
而且,随着CDN级联[6]技术方案的应用,上级CDN进一步地将源网站的内容代理至下级CDN,上述的关于密钥管理、代理关系管理和代理关系验证的问题会变得更加严重.
例如,当源网站撤销上级CDN向下级CDN的内容代理关系时,需要考虑多级CDN的关系.
针对这些问题,我们提出了一种发布、管理、验证源网站和CDN之间内容代理关系的方案DET(DelegationTransparencyforHTTPSwithCDNs).
DET设有日志服务器,公开地记录所有源网站和CDN之间的代理关系.
日志通过公开的、唯一的、前后一致的、基于树的结构,展示所有参与的源网站和CDN的代理关系信息,从而实现源网站代理关系的公开可验证和查询.
同时,日志服务器也周期性地收集源网站和CDN对日志信息的操作,并将执行过的操作添加在公开的操作记录中,作为审查的依据.
与传统的证书透明化方案不同,DET将源网站和CDN的代理关系(而不是证书)记录在公开的日志中.
我们使用有向无环图描述源网站到CDN的代理关系,使得源网站可以使用哈希值表示完整的代理关系,且代理关系可以被高效地传输和验证.
在代理关系的计算时,我们引入了变色龙哈希函数,使得CDN的SSL/TLS密钥改变不影响代理关系的表示,此时源网站无需更新代理关系.
源网站为CDN产生基于密码学的证据,证明CDN被授权代理其内容,以及(可选的)CDN级联时内容从源网站到该CDN的分发路径.
浏览器结合公开日志中的代理关系信息验证上述证据.
日志服务器可以被任何利益相关方(例如源网站、CDN或公共服务机构等)随时、公开地监督,检查其中发布的信息是否正确.
一旦这些信息发生错误,利益相关方可以及时发现.
同时,日志服务器可以被公开审查.
日志服务器产生公开的基于密码学的证据,使得其无法在不留下证据的情况下作恶.
网络中的任何实体,均可充当审查机构,根据日志服务器提供的证据在线地验证日志服务器的状态,确保日志服务器的正确运行.
通过将内容分发网络的代理关系透明化,DET提供了如下现有方案不具备的、对CDN应用非常重要的特性.
18JournalofCyberSecurity信息安全学报,2018年3月,第3卷,第2期1)独立的密钥管理DET将内容代理的授权和共用私钥解耦合.
在DET中,内容代理关系通过日志服务器中的日志信息被显式地表达.
CDN和源网站独立拥有、管理各自的SSL/TLS公私钥.
SSL/TLS公私钥的更新不会影响源网站和CDN之间代理关系的表达.
这避免了CDN集中管理大量源网站的私钥,或使用一个绑定了大量源网站域名的私钥.
2)主体可控的代理关系源网站可以独立、实时地在日志服务器中管理(初始化、更新、撤销)自身的所有代理关系,不需要借助自己或者CDN的CA.
源网站可管理的代理关系,包括从自身到CDN的内容代理,也包括(CDN级联时)上级CDN到下级CDN的内容代理.
3)浏览器可知当浏览器通过HTTPS连接CDN时,CDN代理服务器在SSL/TLS连接握手消息中加入源网站提供的证据;浏览器验证通过后,使用CDN自身的证书建立HTTPS连接.
支持DET的浏览器可根据收到的证据明确得知接收到的内容来自源网站还是CDN;在CDN级联的情形下,浏览器也可验证从源网站到被访问CDN间的多级代理关系.
4)高效操作日志服务器将各个源网站和CDN的信息记录在二叉搜索树中,为依赖方提供高效的查询服务.
日志信息的审查、监督和验证仅包含哈希值计算和签名验证操作,避免了对浏览器、源网站和审查机构造成过高的性能开销.
我们实现了DET原型系统,包括DET日志服务器和支持DET中HTTPS连接方式的CDN代理服务器和浏览器.
在HTTPS连接建立过程中,浏览器验证CDN的证书和代理证据.
我们也实现了源网站和CDN的管理工具,帮助它们管理和监督在日志中的信息.
性能测试表明,我们的方案中浏览器的带宽、计算等各方面开销和日志服务器各项操作效率都是可接受的.
本文的后续章节安排如下.
第2章介绍了本方案的系统模型和安全假设;第3章说明了公开日志的结构;第4章详细阐述了各方的交互过程;第5章和第6章对方案的安全性和性能进行了分析;第7章讨论了技术方案的扩展;第8章介绍了相关的工作;第9章是全文总结.
2系统模型与安全目标DET的设计目标,是提供可显式声明、独立管理、即时撤销、高效验证源网站和CDN之间的内容代理关系的公开日志系统.
2.
1系统角色DET的系统模型包含五个主要角色:日志服务器、源网站、CDN、浏览器和审查机构.
我们将在对应的小节中详细介绍每个角色在系统中的功能和相关的安全假设.
为了使DET方案与现有的PKI、SSL/TLS和CDN应用兼容良好,我们考虑DET运行在现实的网络情况下,即:CDN和源网站都配置了有效的PKI证书;浏览器和日志服务器可以正确地验证数字证书;各角色间有较为宽松的时间同步(允许数分钟级别的误差).
我们假设使用的密码学方法是安全的.
在原型系统中,我们使用了SHA256作为通用的哈希函数,使用了基于离散对数的变色龙哈希函数,以及RSA-2048签名/验签算法.
2.
1.
1日志服务器DET将源网站和CDN之间的代理关系记录在日志服务器中.
日志服务器的内容是公开可见的,为方案各依赖方提供一致的信息.
我们仅假设日志服务器可以保证一定程度的可用性,方案各方不必信任日志服务器.
日志服务器可以向审查机构提供证据,证明其按照预定的规则运行.
日志服务器也能为源网站或CDN产生证据,证明相应的信息确实存在于日志中.
日志服务器拥有属于自己的私钥,为上述证据签名.
与证书透明化方案[7]类似,日志服务器的公钥可以预先部署在方案各方之中,也可以从日志服务器的有效数字证书获取.
同时,日志服务器维护一个自己的信任根证书列表,包括了所有被主流浏览器和操作系统信任的根证书.
2.
1.
2CDNCDN将源网站的内容缓存在代理服务器中,并将内容分发至来访的浏览器.
CDN可能从源网站直接获得其内容,也可能从另一个CDN处间接获得(称为CDN级联).
如果是后者,获取内容之前CDN需要确认另一个CDN从级联关系上是否确实是自身的上游(详见7.
2节).
本方案中CDN使用自己的证书公钥与浏览器建立HTTPS链接,不需要与源网站共用证书和私钥.
CDN将自身的信息提交并记录在日志服务器中.
CDN可以随时访问日志服务器,确认关于自身的信息正确.
2.
1.
3源网站为了提供更好的用户体验,源网站授权CDN代理并分发自己产生的内容.
源网站独立地管理自己王泽等:面向HTTPS的内容分发网络代理关系透明化19的内容代理关系,包括哪些CDN被授权代理自身的内容和内容分发的具体路径.
相应地,源网站为CDN生成授权的凭据.
源网站将自身的信息和代理关系提交、记录在日志服务器中.
源网站可以随时监督日志服务器,确认相关的信息正确.
源网站拥有有效的数字证书.
日志服务器和浏览器可以通过验证数字证书得到源网站的公钥.
源网站不需要和CDN共用证书和私钥.
2.
1.
4浏览器浏览器通过HTTPS连接访问源网站.
访问时,浏览器的连接可能被定向到源网站的服务器,也可能被定向到CDN的代理服务器.
在两种情况下,浏览器都能成功地建立HTTPS连接,并可以分辨这两种情况.
当连接到CDN代理服务器时,浏览器能验证该CDN是否被源网站授权代理其内容.
此时,浏览器在使用标准方式验证证书之外,也能够验证DET方案产生的证明CDN代理关系的证据.
验证通过后,浏览器使用CDN的公钥建立SSL/TLS连接.
2.
1.
5审查机构在DET中,审查机构的主要功能是检查日志服务器是否按照预先设定的规则正确地运行.
审查的方式是验证日志服务器提供的证据.
由于所有的证据均可由日志服务器在线提供,审查可以在线独立完成,所以审查机构可以由网络中的任何一方担任.
因此,网络中可以存在大量冗余的、互为备份的审查机构.
例如,每个CDN代理服务器都可成为一个审查机构.
每个审查的地位是平等的,不存在"单点失效"的风险,即:若某些审查机构被敌手控制,其他审查机构的功能不受影响.
我们假设对于任何浏览器、源网站、CDN,都有较多的审查机构可供选择和交互.
此外,审查机构可以帮助浏览器等验证CDN提供的关于代理关系的证据,并返回结果.
综上,DET中各角色的相互关系如图1所示.
2.
2安全目标DET方案的目标是,在源网站和CDN不共用私钥的前提下,浏览器可以和源网站授权代理内容的CDN正确地建立HTTPS连接.
浏览器不会和未被授权的CDN代理服务器建立HTTPS连接.
源网站对CDN的内容代理关系是源网站产生相关证据、浏览器验证证据的依据.
代理关系记录在日志服务器中.
日志的内容是否真实可靠,是安全目标能否成功达成的关键.
由于日志服务器是公开的,其中的所有信息均可在线地获取.
源网站和CDN应定时确认日志中自身信息正确.
为了防止日志服务器向不同的浏览器/源网站/CDN提供不同的关于特图1DET中系统各角色和相互关系的示意图Figure1SystemmodelofDET定代理关系的描述,我们要求日志向各方提供相同的日志内容(称为"唯一性").
审查机构检查日志的操作是否符合预先设定的规则、日志服务器的最终状态和进行过的操作是否一致.
为了防止日志服务器篡改已经经过审查的历史记录,保证日志服务器提供的操作记录是前后一致的、未被篡改的(称为"一致性"),我们要求要求日志服务器的操作历史是仅可添加的(Append-only),即:日志服务器不能回退或否认进行过操作;任何操作,都会留下公开、永久的证据,并在之后的任何时刻均可被检查.
我们为日志服务器设计了可以公开获取和验证的、基于密码学的证据,证明日志服务器满足以上性质(详见3.
2、3.
3节).
3公开日志的结构本章中,我们首先在3.
1节介绍源网站到CDN的内容代理关系的表示,以及代理摘要的生成.
代理摘要和其他相关信息,会记录在公开日志中.
在DET中,日志服务器的日志由两部分组成.
一部分称为"状态树",另一部分称为"操作记录".
状态树是二叉搜索树,记录了每个源网站的代理关系和CDN的特定公钥的最终状态.
操作记录维护了仅可添加的日志操作的完整历史.
操作记录由一系列MerkleHash树时序地级联而成.
日志的两部分相互配合,为各类日志功能提供高效的、基于密码学的证据.
我们在3.
2节和3.
3节依次介绍状态树和操作记录的具体结构.
20JournalofCyberSecurity信息安全学报,2018年3月,第3卷,第2期3.
1代理拓扑结构和代理摘要代理拓扑结构.
源网站到CDN的内容代理关系可以由相应的代理拓扑结构表示.
代理拓扑结构完整地描述:1)源网站授权代理内容的所有CDN;2)每个CDN获得源网站内容的具体途径.
为了完整地支持CDN应用,代理拓扑结构可以表示CDN级联,即源网站将内容代理到上游CDN,上游CDN进一步将内容代理到下游CDN.
图2代理拓扑结构示意图Figure2Thestructureofdelegationtopology源网站的代理拓扑结构被抽象为一个有向无环图(DirectedAcyclicGraph,DAG).
如图2所示.
图中有唯一源节点,代表源网站;每个非源节点代表不同的CDN;图中任何一条有向边,表示由上游内容提供者(源网站或者CDN)向下游CDN的代理关系.
在代理拓扑结构中,每个CDN节点表示为:CDN节点:=其中SSL/TLS公钥即为浏览器和CDN代理服务器建立HTTPS连接时CDN使用的公钥.
当浏览器和CDN建立HTTPS连接时,CDN应提供有效的数字证书,且证书的主体名和公钥应和CDN节点的内容匹配.
在代理拓扑结构中,源网站的节点表示为:源网站节点:=代理摘要.
代理摘要是根据代理结构生成的一个哈希值.
计算代理摘要的方式类似于计算Merkle哈希树的根节点.
我们对代理拓扑结构的每个节点计算哈希值,并将源网站节点的哈希值称为代理摘要.
如果源网站没有使用CDN,则代理摘要记为NULL.
源网站节点的哈希值为:源网站节点的哈希:=Hash{源网站域名||所有子节点的哈希}其中源网站节点的子节点,指从源网站节点出发的有向边的终点.
所有子节点的哈希按照子节点的域名的字典顺序排列.
需要注意的是,源网站节点的哈希并不是简单地对源网站节点的内容计算散列值,而是应包含所有子节点的信息.
进一步地,对于CDN节点,节点的哈希值的计算方式为:CDN节点的哈希:=Hash{Hash{域名||CH{公钥,r}}||所有子节点的哈希}其中,Hash代表一般的哈希函数(如SHA256);CH代表变色龙哈希函数(ChameleonHash,CH),r是一个随机数.
变色龙哈希函数[8]是一类特殊的设有秘密陷门的哈希函数.
拥有陷门的一方容易计算出哈希的碰撞;没有陷门的一方则很难计算出碰撞(与普通哈希函数具有相同性质).
CDN节点的哈希的计算过程中所使用的变色龙哈希函数的陷门,由节点对应的CDN拥有.
每个CDN都拥有唯一的陷门.
计算变色龙哈希函数之前,需要使用陷门对应的公钥初始化变色龙哈希函数.
本方案中,CDN将自己的变色龙哈希函数公钥(下文简称为变色龙公钥)公开发布在日志服务器中.
由于使用了变色龙哈希函数,当CDN由于证书更新、私钥泄露或其他原因改变其SSL/TLS公钥时,可以为新公钥找到碰撞(即新的随机数r).
在新的公钥和相应随机数下,代理拓扑结构中该CDN节点的哈希可以保持不变,从而代理摘要保持不变.
因此,CDN可以独立地管理自身的SSL/TLS公钥,不引起源网站额外的操作.
直接/多步代理证据.
当连接到CDN代理服务器时,浏览器应要求CDN提供证据,证明CDN被授权代理源网站的内容.
证据分为直接代理证据和多步代理证据.
其中,直接代理证据使得浏览器能够直接验证相应CDN是否具有目标源网站的代理授权;多步代理证据不仅证明了代理授权,还能够体现代理路径中的任意一步或几步.
若浏览器已知源网站的域名和代理摘要,以及CDN的变色龙公钥,直接代理证据使得浏览器可以根据CDN的域名和SSL/TLS公钥计算出代理摘要,进而使得浏览器能够验证对CDN的代理授权.
在代理拓扑结构中,CDN的直接代理证据由两部分组成:1)CDN域名和SSL/TLS公钥(即CDN节点的内容),和随机数r(由对应的CDN给出),2)计算代理摘要所必需且最少的额外的哈希值(由源网站预先提供给CDN).
例如,在图2中,CDN1的直接代理证据,由CDN3节点的哈希,CDN1节点的内容和随机数r1,CDN2节点的哈希组成.
多步代理证据可以由直接代理证据扩展得到:只需要将直接代理证据中多步代理路径上的其他CDN节点的哈希,相应地替代为这些CDN节点的内容、计算变色龙哈希的随机数和它们子节点的哈希即可.
例如,在图2中,证明源节点到CDN3的多步王泽等:面向HTTPS的内容分发网络代理关系透明化21代理证据,由CDN3节点的内容和随机数r3,CDN1节点的内容和随机数r1,CDN2节点的哈希组成.
3.
2状态树状态树是二叉搜索树,记录源网站的代理摘要和CDN的变色龙公钥.
状态树的每一个节点均代表一个源网站或者CDN;每一个源网站或CDN在状态树中仅有一个节点.
节点按照源网站和CDN域名的字典顺序进行排序.
一个状态树的示例如图3所示.
图3日志的状态树示意图Figure3Thestructureofstatetreeofpubliclog状态树中代表源网站的节点表示为:源网站节点:=状态树中代表CDN的节点表示为:CDN节点:=由于每个源网站和CDN在状态树中均只对应一个节点,因此源网站的代理摘要和CDN的变色龙公钥都是唯一的.
状态树的哈希.
状态树的哈希是树根节点的哈希值.
与计算代理摘要类似,状态树中每个节点的哈希计算为:节点的哈希:=Hash{Hash{域名||代理摘要或变色龙公钥}||左子节点的哈希||右子节点的哈希}节点的存在性/不存在性证据.
如上节所述,浏览器验证直接代理证据时,需要从状态树中获取源网站的代理摘要和CDN的变色龙公钥.
浏览器从状态树获取这些信息时,状态树应能相应地证明这些信息在树中确实存在.
此外,源网站和CDN监督日志服务器,检查日志中自身的信息是否正确时,也要求状态树证明提供的信息确实在日志中存在.
所以,状态树应能够对树中的节点提供存在性证据.
若已知状态树的哈希,状态树中节点的存在性证据由两部分构成:1)节点的内容,2)计算出状态树的哈希必需且最少的所有额外的哈希值.
例如,在图3中,bob.
com的存在性证据,由akamai.
com节点的哈希,cloudflare.
com节点的哈希,bob.
com的域名和代理摘要,flora.
com节点的哈希,Hash{david.
com||david.
com的代理摘要}组成.
有的时候,状态树也需要给出某个源网站或CDN的不存在性证据.
例如,未加入方案的网站需要确定在日志服务器中不存在自己的记录,或者从方案中注销的网站需要确定日志服务器已经在状态树中删除了自己的节点.
不存在性证据由两个相邻节点的存在性证据组成.
例如,对于节点X,其不存在性证据是节点A和B的存在性证据,其中A浏览器验证公开日志服务器的签名,并确认其中CDN域名和公钥与收到的证书匹配,且源网站域名王泽等:面向HTTPS的内容分发网络代理关系透明化27和浏览器的访问目标一致.
如果验证通过,浏览器接受HTTPS连接.
CDN向日志服务器请求简化的代理证据时,需要向日志服务器提供源网站的域名和相应的直接代理证据.
日志服务器验证直接代理证据通过后签发简化的代理证据.
浏览器可将收到的简化的代理证据提交到审查机构.
审查机构进一步向日志服务器申请完整的代理证据并验证,将验证结果异步地返回给浏览器.
如果审查机构验证不通过,也会认为日志服务器运行不正确.
此过程中,浏览器向审查机构暴露了自身的访问行为;同时,审查机构对完整的代理证据的验证结果一般晚于HTTPS连接的建立.
7.
2防范转发环路攻击转发环路(forwarding-loopattack)攻击[13]是由恶意源网站发起的针对CDN的攻击.
在转发环路攻击中,恶意源网站要求多个CDN互相请求关于源网站的内容,从而构成环路.
特别地,由于CDN拥有大量的代理服务器,对内容的请求可能由少量的代理服务器传播到更多的代理服务器,产生急剧扩大的效应,对CDN的可用性产生严重威胁.
转发环路攻击产生的根本原因在于,在多个CDN同时存在时,CDN获取源网站内容的路径缺乏无环约束.
文献[13]认为的最可行的解决方案是,CDN在HTTP头部特定字段记录内容的获取来源.
下游CDN向上游CDN请求内容时,需要检查内容的每一步获取路径,避免环路的发生.
然而,该方案需要所有CDN合作,才能防止转发环路出现.
环路中任何一个恶意的CDN和源网站合谋,都可能使得该方案失效.
DET可以防止转发环路攻击.
当下游CDN向上游CDN请求源网站内容前,需要获得从上游CDN到自己的多步代理证据.
下游CDN验证上游CDN和自己在代理拓扑结构中有直接的上下游关系.
若验证不通过,则下游CDN拒绝向上游CDN请求源网站内容.
由于代理拓扑结构是无环的,因此任何人(包括源网站)无法生成同时成立的、可构成环路的多步代理证据.
注意,本方案不需要所有CDN合作即可抵御转发环路攻击.
7.
3与证书透明化合作部署证书透明化方案[7]建立了公开可审查的日志结构,记录所有有效的证书.
证书透明化的日志是仅可添加的,一旦证书被添加到日志中就永远不会被删除.
通过扩展证书透明化日志,我们可以将对DET日志的操作保存在证书透明化的日志中.
这时,DET的日志服务器仅需维护状态树,而将所有进行过的操作添加到证书透明化的日志中,由证书透明化日志产生签名的树根.
同时,可以将证书透明化方案中的网站公钥和证书策略的信息加入到DET日志服务器的状态树中,使得对网站公钥和证书策略的查询更为高效,降低网站监督证书透明化方案日志的开销.
另外,证书透明化方案也可以保护PKI系统,缓解虚假证书可能带来的危害.
在DET中,日志服务器和浏览器依赖PKI系统验证源网站和CDN的公钥.
PKI系统安全性的提升,可以相应地提升我们方案的安全性.
8相关文献8.
1CDN代理关系2014年,文献[4]首次提出了CDN和源网站共用私钥的问题,深入分析了CDN服务器为浏览器提供HTTPS服务的原理.
2016年,文献[5]进一步广泛调查了数字证书主体与其他组织共用证书私钥的现状.
文献认为,至少76.
5%的证书中主体与其他组织共用私钥.
针对CDN和源网站共用私钥的问题,已经有一些解决方案被提出.
文献[4]探讨了名字限制证书(NameConstraintCertificate)方案,允许源网站拥有名字限制证书.
源网站可以使用名字限制证书进一步为CDN签发有效的数字证书,所签发证书的主体限制为源网站域名.
然而,此方案的实用性较差,由于:1)CA不太可能为源网站提供名字限制证书;2)源网站需要实现CA的部分功能,开销过大;3)现有浏览器对名字限制证书的支持程度较低.
文献[4]提出了基于DANE[14]的解决方案,源网站可以在DANE的资源记录中声明目前在用的CDN和CDN的公钥.
然而,有研究[15]表明目前在所有HTTPS网站中,DANE的部署率不足0.
05%.
另外使用DANE会造成浏览器多次请求DNSSEC资源记录,在一次HTTPS连接中可能导致长达数秒的时间开销[16].
在Keyless[17]方案中,CDN不拥有源网站的私钥,无法独立完成SSL/TLS会话密钥协商.
SSL/TLS握手过程中,CDN将浏览器发送的部分消息转发至源网站,在源网站的协助下产生会话密钥.
这要求源网站参与到每次HTTPS建立过程中,面临可伸缩性的问题,违背了CDN带来的性能收益.
另一方面,HTTPS建立过程中CDN需要连接源网站,造成额外延迟.
代理凭据(DelegatedCredential)[18]方案中,源网28JournalofCyberSecurity信息安全学报,2018年3月,第3卷,第2期站签发短期的代理凭据(包含CDN的名字和SSL/TLS公钥),证明源网站到CDN的内容代理关系.
代理凭据随SSL/TLS握手消息推送,由浏览器验证.
此方案中源网站无法撤销已经签发的凭据,只能等待凭据失效.
同时,每当CDN更换SSL/TLS公钥,或者凭据过期时,源网站需要再次签发凭据,造成较大的负担.
另外,在CDN级联的情形下,凭据的格式无法表示源网站到被访问CDN的完整的内容代理路径.
OOB(Out-of-BandforCDNI)[19,20]方案中,浏览器首先访问源网站的服务器,获得源网站的资源映射文件.
浏览器根据获得的资源映射文件,访问指定的CDN获取源网站的内容.
OOB要求源网站为每个HTTPS连接提供映射文件,违背了CDN带来的性能收益.
同时,一次访问中浏览器需要同源网站和CDN建立多个连接,降低了用户体验.
在CDN级联的情形下,浏览器从多个CDN依次得到资源映射文件,造成的延迟会更加严重.
Lurk(Limited-use-of-remote-keys)[21]和STAR(Short-term,automaticallyrenewedcertificate)[22,23]方案中,由源网站向CA申请,CA周期性地签发短期证书(short-livedcertificate),并向CDN提供这些短期证书和私钥.
一旦代理关系结束,CA机构不再签发此类短期证书.
这些方案虽然可以一定程度缓解代理关系的撤销问题,但是由于短期证书依然还对应源网站的域名,所以代理关系对浏览器依旧不透明.
综上,已有的方案均无法同时实现浏览器可知、独立的密钥管理、主体可控的代理关系和性能高效可实用的要求.
8.
2公开日志相关应用目前已有的基于公开日志的方案主要用于防范由虚假证书带来的各类攻击.
虚假证书是一类由CA机构错误签发的证书,将证书主体名字和不属于证书主体的公钥绑定起来.
虚假证书可以被用来发动身份冒用攻击.
2013年,谷歌公司提出证书透明化方案[7],旨在帮助发现虚假证书.
证书透明化方案中,浏览器验证证书时,要求证书必须出现在公开的日志服务器中.
网站定期查看公开日志服务器,检查是否有关于自己的虚假证书.
与证书透明化方案不同,DET主要实现对源网站内容代理关系的管理和验证.
因此,我们的方案中将代理关系,而不是证书,发布在日志服务器中.
证书透明化中,日志是一个记录所有证书的Merkle哈希树(对应于DET中操作记录的部分).
因此,检查日志中某个网站的证书需要遍历日志中所有证书.
为了提高查找效率,CIRT[24]提出了Merkle哈希树和搜索树结合的结构.
CIRT中,查询一个网站的证书,只需进行O(logN)级别的操作(N为网站数量).
我们的方案部分沿用了CIRT的日志结构.
AKI[25],ARPKI[26],Policert[27]将证书和证书策略加入公开的日志中.
证书策略是由证书主体声明的验证证书的额外要求.
证书策略可以帮助平衡CA的绝对权威,实现对CA信任范围的限定.
将证书加入日志服务器前,或浏览器验证证书时,要检查该证书是否满足主体的证书策略.
这些方案,在实现证书透明化的同时,进一步限制了CA签发证书的范围,增加了敌手产生虚假证书的难度.
PKISN[28]将证书被签发的时间和被撤销的时间也记录在日志服务器中,实现了时间维度上细粒度的证书撤销管理.
Policert、PKISN均采用了与CIRT类似的结构.
CONIKS[29]是一个供身份服务商记录用户ID和公钥的日志系统.
CONIKS实现了对用户公钥信息的隐私保护:知道用户ID,可以在CONIKS中查询ID对应的公钥;不知道用户ID,则无法从CONIKS中得到用户的信息.
CONIKS使用前缀树作为日志的结构,树节点由可验证随机函数产生(Verifiablerandomfunctions).
我们的方案可以结合CONIKS的方法生成状态树,实现日志中源网站和CDN信息的隐私保护.
Insynd[30]相应地提出了一种新的公开日志系统中保护用户隐私的密码学方案.
9结论本文提出了DET,一种基于公开可审查的日志方案,解决目前CDN提供HTTPS服务时源网站私钥存在泄露风险、源网站无法独立且即时撤销代理关系、代理关系对浏览器不透明等问题.
DET使得CDN不必要求源网站分享私钥,就可以为浏览器提供HTTPS服务;浏览器可以明确获知并验证源网站与CDN之间的内容代理关系;源网站独立地管理自己的内容代理关系.
在DET中,日志的所有操作都保存在仅可添加的操作记录中.
日志维护状态树,提供高效的查询服务.
日志提供基于密码学的证据,使得审查机构能够检查其是否正确运行.
DET仅需对SSL/TLS握手过程进行扩展,加入代理证据的验证,与现有的TLS/PKI体系兼容.
DET的性能评估表明DET的各项操作均具有较高的效率,不会对浏览器建立HTTPS过程带来过大的时间(小王泽等:面向HTTPS的内容分发网络代理关系透明化29于1.
58毫秒)和通信开销(约为3.
86KB).
参考文献[1]"ContentDeliveryNetwork(CDN)MarketbyType(Stan-dard/Non-videoandVideo),CoreSolution(WebPerformanceOptimi-zation,MediaDelivery,andCloudSecurity),AdjacentServices,Ser-viceProviders,andRegion-GlobalForecastto2021",http://www.
marketsandmarkets.
com/Market-Reports/content-delivery-networks-cdn-market-657.
html,Nov,2016.
[2]"ContentDeliveryNetwork(CDN)Marketworth$12.
16Billionby2019",http://www.
marketwatch.
com/story/content-delivery-network-cdn-market-worth-1216-billion-by-2019-2014-03-27,Mar,2014.
[3]"GlobalContentDeliveryNetworkMarket(2016–2022)",https://www.
giiresearch.
com/report/kbv406073-global-content-delivery-network-market.
html,Nov,2016.
[4]J.
Liang,J.
Jiang,H.
Duan,K.
Li,T.
Wan,andJ.
Wu,"WhenHTTPSMeetsCDN:ACaseofAuthenticationinDelegatedService,"inProc.
ofIEEESymp.
SecurityandPrivacy(SP'05),pp.
67-82,2014.
[5]F.
Cangialosi,T.
Chung,D.
Choffnes,D.
Levin,B.
Maggs,andA.
Mislove,etal,"MeasurementandAnalysisofPrivateKeySharingintheHTTPSEcosystem,"inProc.
ofACMSigsacConferenceonCom-puterandCommunicationsSecurity(CCS'16),pp.
628-640,2016.
[6]B.
Niven-Jenkins,F.
Faucheur,andN.
Bitar,"ContentDistributionNetworkInterconnection(CDNI)ProblemStatement,"RFC6707,IETF,2016.
[7]B.
Laurie,A.
Langley,E.
Kasper,"CertificateTransparency,"RFC6962,IETF,2013.
[8]X.
Chen,F.
Zhang,andK.
Kim,"Chameleonhashingwithoutkeyex-posure,"inLectureNotesinComputerScience,pp.
87–98,vol.
3225,2004.
[9]S.
Blake-Wilson,M.
Nystrom,D.
Hopwood,J.
Mikkelsen,andT.
Wright,"TransportLayerSecurity(TLS)Extensions",RFC3546,IETF,2003.
[10]K.
M.
Chandy,andL.
Lamport,"DistributedSnapshots:DeterminingGlobalStatesofaDistributedSystem,"inACMTransactionsonCom-puterSystems,pp.
63-75,vol.
3,2016.
[11]K.
Shvachko,H.
Kuang,S.
Radia,R.
Chansler,"TheHadoopDistrib-utedFileSystem,"inSymposiumonMASSStorageSystemsandTechnologies,pp.
1-10,2010.
[12]F.
Chang,J.
Dean,S.
Ghemawat,W.
C.
Hsieh,D.
A.
Wallach,andM.
Burrows,"Bigtable:ADistributedStorageSystemforStructuredData,"inSymposiumonOperatingSystemsDesignandImplementa-tion(OSDI'06),pp.
205-218,vol.
26,2006.
[13]J.
Chen,J.
Jiang,X.
Zheng,H.
Duan,J.
Liang,andK.
Li,etal,"For-warding-LoopAttacksinContentDeliveryNetworks,"inProc.
ofNetworkandDistributedSystemSecuritySymposium(NDSS'16),2016.
[14]P.
Hoffman,J.
Schlyter,andK.
AB,"TheDNS-BasedAuthenticationofNamedEntities(DANE)TransportLayerSecurity(TLS)Protocol:TLSA",RFC6698,IETF,2012.
[15]P.
Szalachowski,andA.
Perrig,"OnDeploymentofDNS-basedSecu-rityEnhancements,"inProc.
ofFinancialCryptoandDataSecurity(FC'17),2017.
[16]R.
L.
Barnes,"DANE:TakingTLSAuthenticationtotheNextLevelUsingDNSSEC",IETFJournal,Oct,2011.
[17]N.
Sullivan,"KeylessSSL:TheNittyGrittyTechnicalDetails",https://blog.
cloudflare.
com/keyless-ssl-the-nitty-gritty-technical-details/,Sep,2014.
[18]R.
Barnes,S.
Iyengar,N.
Sullivan,E.
Rescorla,"DelegatedCredentialsforTLS,"TechnicalReport,IETF,2017.
[19]J.
Reschke,andS.
Loreto,"`Out-Of-Band'ContentCodingforHTTP,"TechnicalReport,IETF,June,2017.
[20]F.
Fieau,E.
Stephan,S.
Mishra,"HTTPSdelegationinCDNI,"Tech-nicalReport,IETF,2017.
[21]Y.
Sheffer,"DelegatingTLSCertificatestoaCDN,"TechnicalReport,IETF,2017.
[22]Y.
Sheffer,D.
Lopez,A.
Perales,T.
Fossati,"UseofShort-Term,Au-tomatically-Renewed(STAR)CertificatestoDelegateAuthorityoverWebSites,"TechnicalReport,IETF,2017.
[23]F.
Fieau,E.
Stephan,S.
Mishra,"CDNIinterfacesupdateforHTTPSdelegation,"TechnicalReport,IETF,2017.
[24]M.
D.
Ryan,"EnhancedCertificateTransparencyandEnd-to-EndEn-cryptedMail,"inProc.
ofNetworkandDistributedSystemSecuritySymposium(NDSS'14),2014.
[25]T.
Kim,L.
Huang,A.
Perrig,C.
Jackson,andV.
Gligor,"AccountableKeyInfrastructure(AKI):AProposalforaPublic-keyValidationInfra-structure,"inProc.
ofInternationalConferenceonWorldWideWeb(WWW'13),pp.
679–690,2013.
[26]D.
Basin,C.
Cremers,H.
Kim,A.
Perrig,R.
Sasse,andP.
Szalachowski,"ARPKI:AttackResilientPublic-KeyInfrastructure,"inProc.
ofACMConferenceonComputerandCommunicationsSecurity(CCS'14),pp.
382–393,2014.
[27]P.
Szalachowski,S.
Matsumoto,andA.
Perrig,"PoliCert:SecureandFlexibleTLSCertificateManagement,"inProc.
ofACMConferenceonComputerandCommunicationsSecurity(CCS'14),pp.
406–417,2014.
[28]P.
Szalachowski,L.
Chuat,andA.
Perrig,"PKISafetyNet(PKISN):AddressingtheToo-Big-to-Be-RevokedProblemoftheTLSEcosys-tem,"inProc.
ofIEEEEuropeanSymposiumonSecurityandPrivacy(EuroS&P'16),pp.
407-422,2016.
[29]M.
Melara,A.
Blankstein,J.
Bonneau,E.
Felten,andM.
Freedman,"CONIKS:BringingKeyTransparencytoEndUsers,"inProc.
ofUSENIXConferenceonSecuritySymposium,(USS'15),pp.
383–398,2015.
[30]R.
Peeters,andT.
Pulls,"Insynd:ImprovedPrivacy-PreservingTrans-parencyLogging,"inProc.
ofEuropeanSymposiumonResearchinComputerSecurity(Esorics'16),pp.
121-139,2016.
30JournalofCyberSecurity信息安全学报,2018年3月,第3卷,第2期王泽于2013年在莱斯大学电子信息工程专业获得工学硕士学位.
现在中国科学院信息工程研究所/中国科学院大学网络空间安全学院信息安全专业攻读博士学位.
研究领域为网络安全.
研究兴趣包括:PKI、DNS、网络身份管理、区块链技术安全等.
Email:wangze@iie.
ac.
cn李文强于2016年在华中科技大学软件工程专业获得工学学士学位.
现在中国科学院信息工程研究所/中国科学院大学网络空间安全学院网络空间安全专业攻读硕士学位.
研究领域包括:网络与系统安全.
研究兴趣包括:虚拟化安全、网络身份管理等.
Email:liwenqiang@iie.
ac.
cn蔡权伟于2015年在中国科学院信息工程研究所信息安全专业获得工学博士学位.
现任中国科学院信息工程研究所助理研究员.
研究领域为网络与系统安全.
研究兴趣包括:分布式容错系统、web安全、网络身份管理等.
Email:caiquanwei@iie.
ac.
cn