清华大学教授段海新:网络空间中的信任与冲突: Web PKI

数据隐私专题

清华大学教授段海新:网络空间中的信任与冲突: Web PKI

我们今天已经离不开的电子商务等应用的安全建立在基于可信第三方的公钥基础（PKI）之上，而PKI的安全一定程度上仍然依赖于彼此之间的信任，而不是固若金汤的安全防范措施。

基督教中，上帝是万能的，虽然人们看不见他、不知道他怎么工作，但是人们相信上帝从来不干坏事，也不会犯错误。信仰者不会问为什么，只需要相信，这就是“trust”。现代科学是质疑一切没有证据的观点，然而，尽管互联网对抗各种攻击增加了许多安全机制，但许多安全机制并非依赖于完美的、可证明的理论，追根究底仍然依赖于人们之间善意的合作与信任，目前的互联网仍然依赖信任与合作才能保持安全可靠运行。

继清华大学“网络空间安全论坛”关于路由和域名的可信任讨论之后，我将继续讨论公钥基础设施（PKI）中基本的信任机制和攻击方式，并结合典型的案例分析互联网基础服务存在的风险。

Web PKI的信任机制

我们不信任路由、不信任DNS，因为攻击者可以利用他们实现重定向、劫持、窃听等攻击；但是通常我们认为把流量加密以后就可以抵御这些攻击，因为密码协议的设计目标就是在不安全的网络中也能实现安全的通信。现在，以密码技术为基础的TLS／SSL已经成了无处不在的安全应用的基石。

涉及到开放环境中的加密和认证，目前主流的商业应用中很难脱离可信第三方，在Web应用中也就是我们要讨论的Web PKI，它是 SSL/TLS 的基石，X.509 证书是HTTPS 的关键要素。单独看每一个CA，它所签发证书的这个信任链就像是一棵树。因为世界上有许多这样的CA，所以整个互联网的信任模型是一个森林状的结构，如图1所示。

图1　CA森林状的信任模型

我们现在所说的Web PKI是IETF PKIX 工作组开发的标准——Internet PKI或 Web PKI，其工作原理是：Subscriber提交 CSR(Certificate Signing Request)；RA/ CA验证 Subscriber 身份；CA 签发证书；在Web服务器上部署证书。

当通过浏览器访问网站时：服务器在TLS握手过程中出具证书；浏览器验证证书链的有效性；如果验证通过，则协商会话秘钥，继续通信；如果不通过，弹出告警。

几乎所有商务应用都依赖CA/HTTPS/ TLS，目前各种浏览器或操作系统预置了上百个Root CA，每个CA可以为无数个中间的CA签发证书。这些Root CA和中间CA所签发的证书都被视为合法。

然而，这些作为互联网安全基石的CA是怎样运行的，除了CA行业以外的其他人很少了解，他们像上帝一样存在着。实际上，这些CA的运行标准或规范并没有一个类似政府或联合国一样的官方机构来制定，而是来自于CAB论坛（CA/ Browser Forum）这样一个完全由商业公司组成的志愿者组织。

Web PKI的常见问题

Web PKI从最初的设计到具体的实现都有一些问题，常见的问题包括以下几种。

信任模型的问题

任何一个CA都可以为任何一个网站签发证书，无需该网站的同意。拿到这种非授权的证书，可以构造一个假冒的网站，用户的浏览器在访问这种服务器时不会产生告警。CA签发未经授权这种证书服务器证书的事件曾经发生过多起，其中包括：

2015年9月，谷歌发现世界最大的CA赛门铁克签发了几个域名为www.google.com和google. com的证书，后来赛门铁克开除了几个违反公司操作程序的员工。2001年通过CA的审计发现VeriSign签发了自称来自微软申请的代码签名证书；

2015年3月，谷歌威胁要从可信CA列表中删除CNNIC CA的根证书，原因是CNNIC为埃及公司MCS Holding签发的中级CA证书被部署到防火墙中，用于动态伪造任何网站证书并劫持所有HTTPS通信。

图2　中间人通过伪造但有效的证书发起攻击

2011年荷兰CA DigiNotar被攻破，伊朗用户在伊朗发现大量伪造的*.google. com证书。这一事件导致DigiNotar公司的根CA证书被主流浏览器或操作系统厂商删除，并最终彻底破产。

证书申请过程中的验证问题

多数CA是商业公司，证书申请流程自动化是他们能够赢利的必由之路。因此，互联网上多数服务器证书只是只验证了域名的DV（Domain Validation）证书，CA通常只是验证申请者的电子邮件属于申请域名的管理员。然而，这种验证也经常出问题。

Mike Zusman在2008年的DEFCON上展示了他从CA厂商Thawte骗取的一个Login.live.com的证书，因为Thawte认为邮箱sslcertificate@live.com应该属于live. com的管理员，而实际上live.com是用户可以自由申请的公用邮箱。

2015年类似的事情再度重演，一个芬兰人用hostmaster@live.fi信箱从Comodo骗取了一个签发给live.fi网站的证书。

用户忽略告警

我们大家都在12306网站上购买火车票，而12306网站在用户购票过程中，浏览器会弹出一个告警，告知用户这是不受信任的CA所签发的证书。

这种证书会有什么问题呢？如果这个环节中出现中间人，模仿12306，用户访问时同样也会弹出一个告警，这导致用户无从区分这个网站究竟是真实的还是来自攻击者。PKI的目的是为了有一个可信的第三方之后，用户可以通过是否弹出告警以区别好的网站和问题网站，而12306将有问题变成了一个常态，用户真的遇到问题的时候，却不知道实际上已经被攻击了。

使用类似不可信证书的公共服务在中国远不止12306，有些银行也是。2013年的中美银行网站的测量表明，美国前一百家银行网站100%都使用可信证书，但是中国300多家银行网站中，32%使用了不可信的CA签发的证书。

公钥证书签名的弱密码算法问题

在公钥证书的签名算法中使用MD5或SHA-1早在2005年前后就已经被证实为不安全的，但是仍有CA使用这两种算法。2005年王小云教授展示了可以产生两个同样签名的、不同的证书，2006年Stevens等人指出可以利用选择前缀碰撞的方法构造了两个ID不同、密钥也不同的证书。直到2008年，他们用这种方法从一个商业CA真正获得了一个假冒的CA证书，证实了这种攻击在现实中是可行的。

2012年，在中东大规模传播的火焰（Flame）病毒就是利用这种技术构造了一个微软的证书，用它对补丁更新文件进行签名，从而入侵Windows系统。

CDN中间人引发的信任威胁

现在主流的网站大部分都是通过CDN提供用户服务，而通过CDN之后，互联网原先端到端的模式，有了一个”中间人”——CDN本身。CDN 是以中间人的方式工作。原始网站是如何授权给中间的CDN 厂商、如何完成浏览器 - CDN - 原始网站之间的身份认证、秘钥交换和数据保护，以及如何撤销这种授权，无论学术界还是工业在以前都没有系统性的考虑。

我们在世界上首先对CDN中的HTTPS部署进行了系统性的研究，研究成果发表在了安全领域的顶级学术会议Security & Privacy上。我们调研了Akamai、CloudFlare 等世界上主流的20个左右的 CDN 服务商，以及一万多个支持 HTTPS 的热门网站（同时也是上述20个 CDN 厂商的客户），揭示出了当前HTTPS 在 CDN 部署中的许多问题。

首先是 CDN 节点和后台源服务器之间的通信很容易受到中间人攻击。我们测试了5个 CDN 厂商的后台通信，发现尽管浏览器到 CDN 节点的通信使用 HTTPS加密，有的厂商使用明文的 HTTP 与后台服务器进行通信；有的厂商虽然使用了HTTPS，却不验证证书的有效性；有的厂商虽然要求合法证书，但是却不验证证书的持有者是谁。

其次是浏览器和 CDN 节点之间的授权认证问题。我们发现很多 CDN 厂商要求源网站提交自己的公钥证书和私钥，这严重破坏了 PKI 安全信任的基本原则，即私钥必须是严格保密、不能与第三方共享的。

另外，现有CDN厂商使用的方案——共享证书(shared certificate)或者客户证书（custom certificate）也存在管理复杂、无法撤销等问题。我们针对Alexa网站上Top 1M的网站，经过7个星期的测量，一共发生了67,290 次证书更换，其中有983个证书被撤销，时间间隔在 0～5 天；有251 个证书被撤销却依然被使用。数据表明，约30% 的证书撤销与更换只更改了密钥，其他信息不变；73% 的证书更换后没有被撤销，绝大部分是 CDN 共享证书。

针对CDN的证书问题，国际互联网工作组IETF也因为我们所指出的问题提出了标准草案。当然，每一种方案时至今日都并没有完美地解决现在的问题，到目前为止，很多时候我们只能是信赖它，为了实现不可信环境下的可靠通信，我们还将要付出巨大的代价。

（本文根据清华大学段海新教授在2016年4月“网络安全研究国际学术论坛”上的演讲内容整理）