Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

安全论文每日读 2015.02.26

这几天Firefox 36.0升级后增加的一个重要的安全特征是停止对RSA1024和RC4的支持,我们今天特地来介绍的一篇讨论TLS协议的前向安全性部署的论文,论文:An Experimental Study of TLS Forward Secrecy Deployments 发表于W2SP 2014学术会议上。

作者:Lin-Shung Huang, Shrikant Adhikarla, Dan Boneh, Collin Jackson

单位:Carnegie Mellon University, Microsoft, Stanford University

Abstract && Introduction

  • TLS中使用DHE或者ECDHE密钥交换,可以保证即使获得服务器私钥也不能重建以前通信使用的会话密钥。
  • 很多网站使用DHE密钥交换来支持前向安全性,但是使用了弱DH参数,带来不安全性。473,802个TLS服务器中,82.9%的使用了弱DH参数。
  • 实验证明传统的部署前向安全性(Forward Secrecy)会降低性能说法不正确,ECDHE密钥交换可能比RSA密钥交换更快。

Background

  • TLS的Cipher suites包括认证算法如RSA和DSA来认证通信方、密钥交换方案来协商bulk Encryption所需的会话密钥、Bulk Encryption cipher比如AES和RC4来加密数据、消息认证算法来生成消息摘要。
  • Forward Secrecy:TLS中,DHE和ECDHE支持前向安全性。服务器长期私钥用来签名短期DH公钥作为pre-master secret生成会话密钥,会话后它被丢弃。
  • 之前的survey主要侧重于发现特定服务器漏洞的普遍性和常见服务器错误配置,本文主要研究PFS的部署和不安全的DHE或ECDHE配置情况。
  • TLS性能评估之前有很多研究,本文第一次进行实验衡量客户端感知到的TLS延迟。

Survey of TLS Servers

主要了解多少服务器支持PFS,它们是否使用了安全的Diffie-Hellman参数。

  • Methodology:
    • 研究Alexa top 1 million 的网站,先扫描443端口找出支持SSL的网站;
    • 用SSLScan扫描器来确定主机支持的SSL协议版本、支持的cipher suites、TLS服务器对cipher suite的偏好;
    • 测试OpenSSL 1.0.1e支持的所有的TLS cipher suites,修改OpenSSL代码来暴露TLS密钥交换的过程,包括从服务器发出的DH和ECDH参数。
    • 用一个python脚本实现并发扫描。
  • Results:对473,802个支持TLS服务器进行扫描。
    • 网站支持的密钥交换方法如下Table 2所示,不同SSL版本支持密钥交换方法不同,文章认为服务器若支持某一版本的SSL协议,就支持某一特定密钥交换方法。总计74.5%的主机支持DHE或ECDHE,其中81%的优先使用DHE或ECDHE而不是RSA。
    • 表3是支持DHE密钥交换的服务器所使用的Diffie-Hellman参数大小。表中可以发现一个服务器可能支持不同大小的参数(百分比相加过100%了).99.3%的使用1024bit,这将被认为长度不够。34%的使用512bit的,大多因为它们支持export cipher suites。
    • 文章发现82.9%的支持DHE的服务器用的DH参数比RSA密钥长度小。61.9%的服务器用较小的DH参数同时优先使用DHE密钥交换。不过使用较短DH参数的原因主要是因为很多主流web服务器不支持,比如Apache2.4.7以前的版本只支持1024bit的DH参数,IIS使用768bit的DH参数。
    • ECDHE链接中,ECDHE密钥没有比RSA签名弱的。因为256bit的ECDHE比2048bit的RSA签名要强。
    • 使用ECDHE的服务器中,有34,145个(40.1%)重用了ECDHE公钥,就是每次链接是服务器没有重新签名新的ECDH参数。不过这可能是出去性能优化考虑,阶段性重新生成新参数。
    • 1.6%的主机使用了匿名密码套件,不提供任何认证,不能抵抗MITM。

Tabel II Tabel III Tabel IV

TLS Performance Evaluation

分别在服务器端和客户端分析不同支持PFS的密码学套件的性能。

  • 用Apache2.4.4搭了服务器,在不同端口建立多个TLS虚拟主机,每个TLS虚拟主机上只能用一种cipher suite。
  • 选择了5个代表性cipher suite用于评估。服务器证书由商业CA签发,共3个。由于主流浏览器不支持DSA-2048bit签名,所以DHE-DSA没有测试客户端性能。

Eval_4 Eval_5

服务器端进行的实验

  • Methodology:
    • 用两台客户机生成综合TLS流量发送给服务器来测试每个TLS服务器的平均吞吐量。
    • 使用ApacheBench Tool这个工具来实现从每个客户机持续并发(同时发1000个请求)地发送HTTPS请求。
    • 监视服务器吞吐量,每5分组取平均值。测试时GET请求和HEAD请求都用。
    • 由于TLS服务器性能可能受页面复杂性影响,设计了3种页面来测试:简单页面、复杂页面、多域名页面。
  • Results:
    • 先观察签名方案相同时,密钥交换方案对服务器吞吐量的影响(RSA-RSA,DHE-RSA,ECDHE-RSA),发现DHE-RSA最慢,RSA-RSA最快,ECDHE-RSA提供Forward Security后性能比RSA-RSA相差不多。
    • 再看不同签名方案对服务器吞吐量的影响,DHE-RSA和DHE-DSA相差无几,而ECDHE-ECDSA比ECDHE-RSA要快很多,而且ECDSA-256安全性比RSA-2048要强。

Eval_6

客户端进行的实验

比较不同TLS cipher suite客户端性能

  • Methodology:
    • 利用Ad Network,在广告内嵌入代码来测试浏览器或网络特性。
    • 两台机器,一台测试TLS服务器,一台广告主机。当广告标题被渲染后,内置的JS代码会发起TLS链接到TLS服务器,脚本会使用HTML5 Navigation Timing API来测试客户端延迟,并把数据发回log server。
    • OCSP查询会导致TLS链接时间误差,在测试前加入“cold”TLS链接来预热客户端OCSP缓存。
    • 购买了273,533个广告曝光。
  • Results:
    • 先测RSA-RSA_COLD和ECDHE-ECDSA_COLD预热OCSP缓存。预热后比较不同cipher suite的情况。
    • ECDHE-ECDSA最快。这意味着部署基于ECC的前向安全性可以提升性能。
    • DHE-RSA在Android上最慢。且IE不支持DHE-RSA。处于兼容性和性能考虑,ECDHE-RSA逗比DHE-RSA要好。
    • 在非Chrome浏览器上测试了TCP+TLS延迟。与chrome上显示结果区别不大。

Conclusion

  • 部署前向安全性影响性能说法不成立。
  • 服务器要正确配置和实现才能得到前向安全性。
  • 推荐使用ECDHE密钥交换替代RSA密钥交换。