@1qaz
2015-10-29T13:58:16.000000Z
字数 1504
阅读 1101
未分类
TLS中RSA默认的填充方式是PKCS#1 v1.5,易受到旁路攻击(Bleichenbacher oracle)
TLS1.3 移除了PKCS#1 v1.5的支持,但这仍不足够避开pkcs#1 v1.5的弱点。由于老版本的存在,仍可被cross-protocol-version attack
签名
h := H(M)
m := 0x01||0xFF||...||0xFF||0x00||ASN.1||h
消息M的签名即m^d mod N
加密
m := 0x00||0x02||PS||0x00||k
c = m^e mod N
c' = (c*s^e)mod N = (ms)^e mod N
输入c',oracle返回1时, 2*B≤ ms mod N < 3*B ,B=2^(8*(l-2))
不断选择新的s,可以减小m的范围,最后只剩一个值
对于1024bit的N,大约需要1 million oracle 查询来恢复明文
Manger's attack
针对PKCS#1 v2.0(RSA-OAEP)
对于1024bit的N,大约需要1100次oracle 查询。
Bleichenbacher oracle 相比于 Manager oracle的不同在于manager每次查询会泄露m中大约1个比特的信息,但manager需要一个perfect oracle,没有false-positive/false-negative
RSA signing oracle
1. 客户端C发送TLS1.3 ClientHello,ClientKeyShare
2. 攻击者A截获信息,选择TLS-DHE-RSA,向C回答ServerHello,ServerKeyShare中包含了DH指数
3. A向服务端S发送ClientHello,S返回ServerHello和它的证书。A用该证书应答C
4. 为了完成TLS1.3 session的建立,A需要计算CertificatVerify,包含之前握手信息的签名。攻击者利用pkcs v1.5的oracle构造一个rsa签名
5. A和C完成握手后,就实现了中间人攻击
这个攻击是online的,在客户端没有发起ClientHello时,A是无法构造RSA签名的。攻击的可行性在于利用Oracle构造签名的时间要短于客户端断开连接的时间
server: TLS 1.2 TLS_RSA,TLS_DHE_RSA
client: only accept TLS_DHE_RSA
用户什么情况下回等30s来建立连接?
高延迟的公共WiFi,页面加载时用户在另一个tab上,。。。
有些TLS的场景是没有用户参与的,机器间的TLS通信,超时断开的时间要长的多(7700s)
TLS各版本必须支持的套件
TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA
因此在现版本中禁止PKCS#1 v1.5是不可能的
x509证书并没有说明它应该被用在TLS什么版本什么密码套件中,应该被用于加密,还是用于签名(TLS_RSA,TLS_DHE_RSA);OpenSSL没有提供为不同TLS版本和密码套件使用不同RSA证书的方式;多个证书需要更多经费