Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Measurement and Analysis of Private Key Sharing in the HTTPS Ecosystem

作者:Frank Cangialosi,Taejoong Chung,David Choffnes,Dave Levin,Bruce M. Maggs,Alan Mislove,Christo Wilson

原文:地址

单位:University of Maryland,Northeastern University,Duke University and Akamai Technologies

出处:CCS 2016


Abstract

在网上通过HTTPS进行身份验证过程中,若Alice所连接的服务器具有Bob的证书以及私钥,则认为通信的对方身份就是Bob。而在现如今互联网中引入了CDNs (Content Delivery Networks),网站服务提供者可能会将自己的私钥与第三方CDN公司进行共享,这将对身份验证起到负面影响。

本文主要做出了如下贡献:

  • 提出了有效分辨网站证书拥有 (owns)、提供 (serves) 以及管理 (manage) 者身份的方法
  • 将这些方法首次应用于研究HTTPS私钥共享问题,发现这种practice已经十分普遍
  • 研究发现很多网站将证书的管理交给第三方负责,且相比自己管理,第三方更加安全

SSL证书

证书中由Common Name字段指定其所属对象,比如说CN=www.example.com代表这个证书是由域名为www.example.com的网站使用。若要在证书中包含许多域名,则可以将这些域名加入Subject Alternate Names (SAN) list,如若SAN list=[*.google.com,*.youtube.com],则这个证书可以供www.google.comm.youtube.com等域名使用。

由于传统的TLS默认一个IP地址对应一个域名,因此在使用虚拟主机服务时,需要解决一个IP地址host多个网站的问题。Server Name Indication (SNI) 是一个TLS扩展,当用户连接网站IP的时候提供需要访问的域名,服务器检查域名从而返回正确的内容。

Hosting提供商

目前很多网站都使用CDN的虚拟主机服务来提升速度或者防御DDos攻击,而且随着HTTPS的普及,很多网站都通过第三方服务提供HTTPS内容。网站托管商主要使用的托管方式如下:

  • 一个客户对应一个IP地址:在托管客户网站时,就限制一个IP地址只能提供一个客户的证书,因此不需要浏览器支持SNI,同一客户的不同域名可置于SAN list
  • 多个用户使用同一IP:浏览器用户连接时需要使用SNI指定想要访问的域名,根据SNI来返回不同客户所对应的不同证书。
  • 使用Cruise-liner证书:网站代理商制作一个在SAN list中包含许多不同客户域名的证书,如SAN list=[monsanto.com,aaa.com,jazzercise.com],因此可以使用一个证书来托管许多网站。

“key sharing”

本文定义key sharing为:某IP地址所提供的证书中的Common NameSAN list中包含有不属于本IP地址所有者控制的域名。key sharing的可以是网站用户直接将自己的密钥交给托管服务商,或者是用户给予托管服务商对密钥的访问权限。

为什么研究key sharing的问题?因为通信加密的整个体系就是建立在密钥的私有性质上面的,一旦它被第三方获知,那么信息就可能会遭到窃听和篡改。另外,当十分多的网站都在为数不多的几家云服务商上进行key sharing时,就有可能产生信任对象中心化的趋势,因此其潜在影响需要被仔细分析。

数据集

A. SSL证书

研究对整个IPv6地址空间进行扫描,获取443端口提供的证书,从2013年10.30到2015年3.30,一共观测到了38,514,130个证书,其中5,067,476为有效证书,其中包含了2,552,936个域名。

B. ASN以及所属组织

由于并非所有的IP地址都提供了反向DNS解析,因此需要根据IP地址所处的ASN (Autonomous System Number)来确定IP所属组织。比如MIT的AS为3,Chicago Public Schools的AS为1416。通过下载数据集,可以获得IP-to-AS的一一对应关系。

C. WHOIS

通过WHOIS查询,可以获取域名所有者的注册信息,但由于WHOIS数据没有标准格式,因此获取起来具有挑战性。通过在Bulk WHOIS数据库上查找,作者最终获得了证书中86.0%的域名的WHOIS信息。

方法论

A. 确定域名所有者

研究者根据域名的WHOIS信息获得邮箱地址,再绘制处关系图,将邮箱相同的域名归为同一个组织,最终获得1,213,996个。

fig1

在所得结果中,有存在包含很多域名的组织,如下表所示,为一些大型的政府或企业。

fig2

另外还存在一个证书包含了不同组织的情况,多数证书 (96.8%) 都为同一个组织所有,而若一个证书中包含了15-30个不同的组织,它一般都是CloudFlare颁发的cruise-liner证书。

fig3

B. 确定网站托管者

通过查找IP地址的反向DNS记录以及ASN,并手动从出现频率最高的前100个组织名称中筛选出了46个第三方网站托管服务商,其它的为组织所有者本身 (e.g., Yahoo Japan),或者ISPs (e.g., AT&T)。

作者总共将101,306,358个IP地址map到了具体的web hosting组织上,占总IP的77.7%:

fig4

结果

A. 多少组织分享了它们的密钥?

8.8%的证书使用了第三方托管,另外还存在同一个密钥为几百家第三方所使用的情况,比如说Google的“global cache”就将内容存放在上千家合作伙伴所拥有的网络中。而其中辨认出的76.5%的组织都与至少一家第三方托管商共享密钥。

因此,作者得出的结论是,密钥共享现如今已经成为了一个广泛存在的行为。

fig5

另外,有22.7%的Alexa top-10K网站共享了它们全部的证书私钥,这些流行的网站倾向于使用CDN来提升网站性能,因此经济因素是促使网站进行密钥共享的主要因素。

fig6

B. 网站托管商拥有多少密钥?

图7表示一个网站托管服务商托管了多少个不同的客户的密钥,图8展示了compromise一个服务商可以掌控百分之多少的域名密钥 (然而在这里假定compromise一个服务商就可以获得它所有的密钥):

fig7

fig8

C. SAN list是如何被利用的

研究发现获得的证书中只有4%不包含SAN list,另外92.8%的证书SAN list中的域名与CN中域名对应同一个组织,而3.2%包含不同的组织。值得注意的是,虽然这些证书占比较小,但却包含了总计11.3%的域名。

fig9

证书管理者是谁?

首先,作者找出了所有签发叶子节点 (leaf) 证书的签发证书,发现76%的证书由1%的证书签发。并且作者认为,当网站管理者自己签发证书时,其签发证书分布会与上述结果接近。

接着作者计算每个网站托管服务商$h$中证书被单一证书签发的比例$c$,如果$c$ ≥ 50%,则认为$h$确实在替代客户签发并管理证书。

经过实验验证,作者发现这种方法很好用,因为一些已知不会为客户管理证书的$h$所对应的$c$低于所设定的阈值 (e.g. amazonaws.com: 24.3%, linode.com: 19.5%),而那些已知会管理客户证书的$h$对应的$c$是显著高于阈值的 (e.g. cloudflare.com: 95.5%, incapsula.com: 65.1%)

但是对于像Akamai, Cloudflare这样的托管商支持两种证书管理方式,即代替客户管理或客户自行管理,而本文章提出的方法并不能够很好识别它们。

证书托管的普遍性

由图可知,大概有30%的网站使用第三方证书托管,并且越是popular的网站,托管证书的比例越高。

fig10

托管证书的撤销

作者致力于回答如下问题:网站将证书交由第三方托管将会对证书管理的速度以及全面性造成怎样的影响?

fig12

从图可以看出,在Heartbleed事件出现之后,虽然Outsourced证书的撤销反应速度较Self-managed和Combined证书慢,但最终被撤销的证书数目确更多。而相对于证书的撤销,证书的重颁发速度更快。

总结

本文的主要结论为,互联网上76.5%的组织与第三方网站托管商都存在HTTPS密钥共享,并且排名前十的托管商拥有45.3%域名的密钥,可见这种现象已经十分普遍。然而这其中也存在许多问题,比如说网站托管的集中化会导致密钥的集中化,并且网站将私钥部署在CDN上本身就是对Web PKI的一种破坏。因此,作者认为将来像Keyless SSL这样允许网站使用CDN的同时自行保存私钥的技术很可能会受到广泛应用。