@1qaz
2016-03-22T09:33:05.000000Z
字数 1470
阅读 1265
TLS
Cross-Protocol
Attack
Nikos Mavrogiannopoulos et al. Leuven, Belgium , CCS'12 pdf
概述:中间人筛选TLS ServerKeyExchange时被服务器签名的ECDH参数,发送客户端解析成合法的DH参数,以实现 可能的(2^-40) MITM
可以看做Wagner and Schneier(1997) 对 SSL3.0 攻击的扩展
Contribution:
1. 以远低于攻破密码学原语的复杂度实现TLS的MITM
2. 证明TLS有更多的cross-protocol attack可能性
3. 对DH参数的基本检查是不足以保护协议的
RSA-EXPORT:512比特RSA,在2006年TLS 1.1中被废除
ECDH
关键问题:SSL3.0在进行DH密钥交换时,服务端发送的ServerKeyExchange中对参数的签名只包括算法的参数和client/server random,并没有算法本身。(其实TLS1.0-1.2也是如此)
在另一个密钥交换算法不同的连接中重放ServerKeyExchange
Adversary与client建立TLS-RSA-EXP,与server建立TLS-DHE-RSA,Adversary将DH的ServerKeyExchange发送给协商为RSA交换的client,client将DH的模数p、生成元g字段解析为RSA的模数m和公钥e。client的k^e%m = k^g%p,对其求模p的g次方根就得到k,即premaster secret。
利用了RSA-EXP可以由服务端自定义RSA参数
“fails due to a paranoid sanity check in implementation"
DH多了一个参数Ys,RSA解析完后长度不对
自定义椭圆曲线:curve_type=1 explicit prime curves (选择原因:参数的结构? 常用的是named curves)
NSS、OpenSSL、GnuTLS并不支持任意的椭圆曲线。。。
符合条件的ECDH ServerKeyExchange:
1. 能被解析成合法的DH ServerKeyExchange(长度)
2. adversery能够恢复出DH key
Lp = 256 + Lq
DH的p的尾部字节,以及Lg,g,LYs,Ys来自ECDH公钥部分,有概率使得长度一致。
Lq + C <= Lp <= C+3*Lq-6
262 − 2Lq <= C <= 256
300~400 bit的椭圆曲线符合条件,secp384r1
概率估计
假设有合法的DH ServerKeyExchange,第二步恢复DH key
分解p?单位根?
Ys=0,1,-1?
2^40?
two 24-CPU Intel Xeon,Gigabit Ethernet,nxweb with GnuTLS 3.0.20
3770/s -> 9 years for 2^40
主流浏览器的TLS 握手超时时间 ~30s
attack random client?
Google 700M visitors per day -> 17 minutes
签名时加上算法名称
The Horton Principle:
Authenticate what is being meant, not what is being said
PuTTY里的RSA key exchange for SSH