%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BASSL%E5%AE%89%E5%85%A8%E9%97%AE%E9%A2%98

SSL的安全之路

刘慧

密码与计算机安全实验室 (LoCCS)

GoSSIP Summer School, 2015.7.20

密码与计算机安全实验室软件安全小组

• 研究方向– 应用密码学

• 乌云特邀专栏– Gossip on SSL Security– GoSSIP_SJTU– http://zone.wooyun.org/content/20229

• 风声——中间人攻击框架– https://github.com/liuhui0613/TheWind

• @步步不会取名字

关于我

• SSL协议介绍

• SSL协议CBC加密模式的安全问题

• SSL协议的降级攻击

• SSL中弱PRNG带来的安全问题

• SSL协议CA/B模型下的安全问题

• 移动平台中SSL的安全问题

• SSL协议的若干加固方案

Outline

SSL协议是为网络通信数据传输提供机密性和完整性的一种安全协议

SSL协议简介

SSL协议简介

SSL协议包含握手、交换密码规范、警告和记录层四个子协议

• Handshake：协商安全参数和密码套件、身份认证、密钥交换• ChangeCipherSpec ：一条消息，表明握手已完成• Alert ：对握手协议中一些异常的错误提醒，Fatal和Warning• Record ：包括对消息的分段、压缩、消息认证和完整性保护、加密

等

SSL协议的设计哲学

SSL协议简介

协议分为两个阶段：• 握手阶段双方协商会话密钥• 握手结束后进入使用会话密钥加密通信

数据过程

x509证书验证通信者身份公钥密码协商密钥对称密码传输数据

SSL协议简介

基于RSA的密钥交换

SSL协议简介

基于Diffie-Hellman的密钥交换

X509 PKI体制

SSL协议简介

SSL协议发展

SSL协议历经多次版本变迁，安全性在发现问题和解决问题的过

程中不断提升

支持认证加密模式禁用MD5-SHA1组合的数字签名

使用HMAC

SSL1.0

握手阶段协商密钥 MAC覆盖填充长度证书链

TLS1.0

SSL2.0

SSL3.0

Finished认证

SSL3.0版本发生重大改变，引入后续版本依赖的基本机制

TLS1.1

TLS1.2

IETF将SSL标准化后更名为TLS，TLS 1.0版本与SSL 3.0差别非常小

ChangeCipherSpec必须在Finished消息之前出现

添加针对CBC模式攻击的保护

注：为方便表达，后面在没有特别指明版本的情况下，均用SSL来指代SSL/TLS

SSL协议实现在现实中，有遵照协议规范的不同版本的SSL实现

GnuTLS

Bouncy Castle

JSSE

密码库的不正确实现会导致实际中SSL使用的不安全

NSSNaCl

1. SSL协议CBC加密模式的安全问题

SSL协议CBC模式的攻击

Padding Oracle攻击• 对于SSL的Padding Oracle攻击在02年Eurocrypt上提出

• 攻击成功需要两个假设：攻击者可以截获所有经填充并

CBC加密后的消息攻击者可以访问Padding Oracle，

告知其消息填充是否正确Yes/No

密文

填充符合规则？


Padding Oracle攻击• SSL协议使用填充长度对消息进行填充

– 例如，假设分组长度为8，消息长度为11，那么填充为0x05||0x05||0x05||0x05||0x05

• 解密时如下图所示，此时填充合法

密文

中间值

IV

明文


Padding Oracle攻击• 攻击者变换前一块密文的最后一个字节，使得解密后填充

出错，在进行至多256次变换后，会使解密后最后一个字节为合法填充0x0x1，从而得知中间值

密文

中间值

前一块密文

明文

继续对前面字节做同样的操作，得知获取到全部中间值，使用真实的前一块密文值，即可得到原始密文。

Padding Oracle攻击• 攻击需要能够回答消息是否正确填充的Padding Oracle

• 对于SSL来说，如何获取可用的Oracle？– SSL记录层的协议设计决定了密文是对下图所示格式消息的加密

• 如果填充不正确，alert协议会返回填充错误消息

• 若填充正确，则继续验证MAC，不正确会返回MAC验证错误

• Alert协议消息都是加密传送的，因此无法以此得到可用的Oracle


MAC-then-Encrypt

Padding Oracle攻击• 如何获取可用的Oracle？

– 其他途径？


时间旁路信息!

Padding Oracle攻击• 时间旁路信息

– 消息填充合法与不合法时，

攻击者得到返回消息的时间

是不一样的

• 修复方式– 实现中不论填充是否正确，都继续检查MAC


明文/错误

密文

消息符合规则？

填充不合法，返回错误消息填充合法，继续检查MAC，返回正确或错误消息

Δt？

Padding Oracle攻击• 如何获取可用的Oracle？

– 其他途径？


仍旧是时间旁路信息!

Padding Oracle攻击• 时间旁路信息

– 对于特定长度的消息，填充合法与不合法时，

攻击者得到返回消息的时间

是不一样的


明文/错误

密文

消息符合规则？

Δt？

精心构造特定长度的密文，使得填充合法和不合法时传给MAC函数的消息在填充后相差一个块，也就是相差一个压缩函数执行的时间

13字节

Padding Oracle攻击• 针对Lucky13的修补方案

– 加入dummy function处理• 比如当padding不正确时，PolarSSL库就会计算需要额外执行的压

缩函数数目，然后调用一个叫做md_process的函数

– 加入dummy data• 直接执行压缩函数，使不论Padding正确与否，都执行可能的最大

数目压缩函数调用，OpenSSL和Mozilla NSS就是采用了这种方式。


Padding Oracle攻击• 仍旧可以获取可用的Oracle


别样的旁路信息!

Padding Oracle攻击• Lucky 13再次来袭

– 攻击条件• 攻击者与目标机运行在同一物理机上

• 物理机器上开启了内存去重（Memory Deduplication）特性，一种内存优化技术，不同程序使用了相同的页会被指向同一块物理内存。

– 通过Flush+Reload技术，攻击者可以检测到dummy function是否被目标机执行，不同库对应的dummy function被执行，则表明原本会有Lucky 13的Oracle

• 修复方案– 密码库的实现：对于填充合法和不合法的情况，采用同样的函数

处理，并且保证同样的执行流（分支不依赖于消息）

– 使Flush+Reload技术失效，比如可以关闭去重功能，对缓存进行分区，或者载入缓存时进行掩码（基于硬件）。


Padding Oracle攻击• 贵宾犬（Poodle）攻击

“Padding Oracle On Downgraded LegacyEncryption"



正式宣告SSL3.0的“死亡”– 攻击条件：

• 攻击者可以将通信降级到SSL v3

• 攻击者可以控制明文格式

• 攻击者可以修改密文

– 攻击后果：• 获取cookie等明文敏感信息

– 修补措施：• 弃用SSL v3

• TLS ClientHello消息加入TLS_FALLBACK_SCSV防止降级到SSLv3



– 某些实现并没有按照规范正确验证填充，导致使用TLS1.0-1.2的服务器也会受Poodle攻击影响

– 攻击发布时，大约10%的服务器受针对TLS的Poodle攻击

– 修补方式：• 使用正确的实现，打官方补丁

• 从设计上来说，MtE-CBC可以考虑弃用，转而使用认证加密模式（TLS1.2中支持）

– 好消息是截止到15年，已有50%的服务器支持TLS1.2


BEAST攻击• Browser Exploit Against SSL/TLS

• 利用IV不随机– 使用上一条消息的最后一个密文块做IV

– 攻击理论在1995年就被提出，直到2011年被证明实际可行• 通过使用java组件打破浏览器同源策略的限制

– 适用于• SSL v3，TLS 1.0

– 在TLS1.1中已改为使用随机IV• 在当时，TLS1.1还未被广泛采用

• 因此推荐的绕过方式是使用RC4

• 但在13年发现RC4的Bias问题后，RC4也不再推荐使用


2. SSL协议降级攻击

Freak攻击• Factoring RSA Export Keys

• 2015年3月3日

• 针对SSL使用RSA密钥交换的情况

• 攻击原理– 中间人将连接降级到使用出口级密码套件，从而使加密预主密钥

的公钥是512bit

– 客户端会接受SeverkeyExchange消息[CVE-2015-0204]

• 攻击影响– 所有支持EXPORT密码套件的服务器

– 大部分主流浏览器，IE，Chrome，Safari，Opera等等

SSL协议降级攻击

Freak攻击• 中间人攻击，降级使用的密码套件


客户端接受512bit的pk’

Freak攻击


the Distinguished Paper award at IEEE S&P (Oakland) 2015

对于客户端来说，接受了多余的消息，这是密码库实现的问题。即对状态机的维护不当，导致不应有的状态转移

Freak攻击—真实实现


Logjam攻击• 2015年5月20日

• 针对SSL使用Diffie-Hellman密钥交换的情况

• 攻击原理– 中间人将连接降级到使用出口级密码套件，从而使参数(g, p)的p

是512bit

• 攻击条件– 实时计算模数是512bit的离散对数

• 攻击影响– 所有支持EXPORT密码套件的服务器

• Alexa排名前1M中的8%

– 所有客户端


Logjam攻击• 中间人攻击，降级使用的密码套件


客户端接受512bit的p

Logjam攻击• 实时计算离散对数

– 使用数域筛算法，预计算只与p有关

– 攻击代价：7天• 选择多项式+筛选：2000-3000 CPU cores（3h+15h）

• 线性计算：a 36-node cluster with two 8-core Intel Xeon E5-2650 CPUs per node. (120h)

• 离散对数数据库大小2.5G


Logjam攻击• 实时计算离散对数

– 使用数域筛算法，预计算只与p有关，而p的选择十分有限


3. SSL中弱PRNG带来的安全问题

不够随机的密钥Linux中的伪随机发生器

• Linux的PRNG以熵为输入，通常使用的熵源为系统事件，如键盘事件、鼠

标事件、系统中断、硬盘读写、网络中断等

• 随机数的生成包含两个异步过程

– 熵的收集

– 随机数的生成

• 两种生成随机数的方式

– /dev/random: 根据熵池中熵的数量生成随机bit，熵的数量达不到阈值

则阻塞随机数的生成，直到熵收集完成

– /dev/urandom: 用户需要多少随机bit则生成多少bit，即使熵的数量不

够，这种方式生成的随机数可能存在可预测性，不推荐使用

弱PRNG对SSL的影响

不够随机的密钥Linux中的伪随机发生器


不够随机的密钥• 嵌入式设备系统Openwrt中的伪随机发生器

– OpenWRT是嵌入式设备如无线路由器中的Linux操作系统

• OpenWRT提供的密码学服务如SSL终端，SSH服务器，无线加密等

都依赖于Linux中PRNG的输出

• 问题一：

– OpenWRT的熵源很有限（嵌入式设备的通病），没有硬盘，鼠标，键盘等熵源

– 唯一的熵源是网络中断，而网络中断还可能被攻击者观察到

• 问题二：

– OpenWRT在每次重启时不保存随机种子，即它每次重启后的PRNG状态仅和系

统时间相关，是一个可预测的值。


不够随机的密钥• Debian系统的伪随机发生器

– Debian是一种使用广泛的Linux操作系统

• 06年发行的Debian系统中，在修复OpenSSL 0.9.8e版本中一个漏

洞时，误删了随机数生成过程中的熵收集部分，导致生成的公私钥对

均具备可预测性

– 该漏洞08年被披露，后被缓慢修复

– 漏洞披露后受影响服务器更新证书的情况

竖轴为受影响服务器比例，横轴为漏洞披露后的天数


不够随机的密钥• 网络设备中的弱密钥

文章对网络中使用的SSL和SSH密钥进行了大规模的扫描和分析，发现很多密钥都存在公因子（相同的p）甚至相同，进一步的分析表明，问题的根源在于随机数生成时的熵不够。


Usenix Security 12Best paper award

不够随机的密钥


TLS服务器 SSH服务器

服务器总数 12,828,613（100%） 10,216,363（100%）

使用重复密钥 7,770,232（60.50%） 6,642,222（65%）

…有问题的重复密钥 714,243（5.57%） 981,166（9.60%）

…使用默认证书或密钥 670,391（5.23%）

…使用低熵重复密钥 43,852（0.34%）

使用可分解RSA密钥 64，081（0.50%） 2,459（0.03%）

使用可攻破DSA密钥 105,728（1.03%）

使用Debian弱密钥 4,147（0.03%） 53,141（0.52%）

使用512bit RSA密钥 123,038（0.96%） 8,459（0.08%）

有问题的设备总数 985,031（7.68%） 1,070,522（10.48%）

4. SSL协议CA/B模型下的安全问题

证书链的安全验证—叶子证书

• HostName validation（CA）

– 验证邮件

• DNS记录

– DV证书的签发

• [email protected] / [email protected]

• HostName validation（client）

– 检查hostname与访问域名匹配

– 解析问题

• bank.comØevil.com

SSL协议CA/B模型下的安全问题

证书链的安全验证—中间证书和根证书

• 不再安全的根CA

• Comodo, DigiNotar（compromised）

• C. Soghoian and S. Stamm. Certified lies: Detecting and defeating

government interception attacks against SSL. In Financial Cryptography,

2011. （compelled）

• 中间证书不完整验证– Basic constraints

• CA：True

• Pathlen：0


证书链的安全验证—信任的维护

• 证书是否还安全可用

– CRL （Certificate Revocation List）

– OCSP ( Online Certificate Status Protocol）

• 可能的问题– 验证途径被阻断

– 所有权转移• fb.com


证书链的安全验证—实现问题

• 2015.7.9，Alternative chains certificate forgery(CVE-2015-1793)

– This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin

(Google/BoringSSL). The fix was developed by the BoringSSL project.

• 1.0.2c, 1.0.2b, => 1.0.2d

• 1.0.1n and 1.0.1o =>1.0.1p

• SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication

• attempt to find an alternative certificate chain if the first attempt fails

• cause certain checks on untrusted certificates to be bypassed

– such as the CA flag


安全提示• HTTP/HTTPS, EV/DV

– Mobile

– Mixed content

• SSL Stripping

• Spoofing chrome


5. 移动平台中SSL的安全问题

证书验证问题--开发者实现错误

• Mobile平台典型的SSL误用（错误实现）

– 信任所有证书：不校验证书的签名者，自签名证书也接收

– 信任所有域名：不校验证书是否签发给当前所访问的域名

– 信任过多的CA：在PKI体系中，默认认为所有CA都是可信的，但最近几年屡屡有CA被攻破或

者CA被政府等机关控制签发流氓证书，比如DigiNotar，Comodo等

移动平台中SSL的安全性

证书验证问题--Android系统根证书信任无法保证

• 证书校验依赖系统中的TrustStore（根证书）

• Android平台中的Trust Store可以由硬件设备制造商、手机运营商等定制

• 具备root权限的应用也可以对系统的Trust store进行修改，root过的手机

上的恶意应用就可能植入流氓根证书，破坏Android设备上的SSL安全性


版本 2.3.5 2.3.7 3.2.4 4.0.3 4.0.4 4.1.2 4.2.2 4.3.1 4.4.2

官方 128 127 132 134 134 139 140 146 150

HTC 128 128 — 164 170 139 — — 150

索尼 127 105 — 137 134 142 — — 150

证书验证问题—密码库实现错误

• 对于Mobile平台使用较多的SSL密码学库，其中的证书校验实现也

可能有误

• Apple goto fail

– 出现在iOS系统7.0.6版本中，影响所有的iPhone和iPad设备

– 程序员疏忽，多写了一行代码，导致SSL证书签名校验过程被略

过



• AFNetworkings库实现问题

– 没有检查SSL证书是否是颁发给某个合法域名

– 任何使用早于2.5.3版本的AFNetworking的iOS程序都存在漏洞

– 几款国内金融类APP如银联、中国银行、交通银行等纷纷中招


6. SSL协议的若干加固方案

SSL协议的若干加固方案强制SSL使用与安全的证书验证

• HTTP Strict Transport Security（HSTS）策略

– 国际互联网工程组织IETE正在推行的一种新的Web安全协议

– 在HTTP响应头中设置字段，强制客户端使用HTTPS与服务器通信

– 可以用来抵御SSL剥离攻击

• 公证人策略

– 使用分布在不同网络节点的公证人验证同一个服务器的证书，投票决定

证书认证结果，防止部分网络范围内的中间人攻击

• 证书密码技术（Certificate Pinning）

– 将服务器的证书签名硬编码在客户端代码中，帮助进行证书验证

• 基于DNS的认证（DANE）

– 将TLS客户端或服务器的证书备份在DNS中帮助进行证书验证

SSL协议的若干加固方案强制SSL使用—HSTS

• Alexa排名前100万的网站HSTS部署情况

域名百分比（%）

部署HSTS策略的网站数 12,593 —

未将HTTP重定向到HTTPS 5,554 44.1%

设置HSTS头时仅指定HTTP 517 4.1%

重定向到HTTP 774 6.1%

HSTS重定向到非HSTS 74 0.6%

格式错误的HSTS头 322 2.6%

Max-age=0 665 5.3%

SSL协议的若干加固方案安全的证书验证—公证人策略

• 常见攻击场景

SSL协议的若干加固方案安全的证书验证—公证人策略

• 一种借助好友作为见证人的解决方案

TagDroid：Hybrid SSL Certificate Verification in Android, ICICS2014

SSL协议的安全性

—设计与实现并重，错一步满盘皆输

密码系统 = 设计+实现

谢谢！

[email protected]

密码与计算机安全实验室软件安全小组

Group of Software Security in Progress (GoSSIP)

@Lab of Cryptology and Computer Security (LoCCS)

• 联系我们– http://loccs.sjtu.edu.cn/wiki/doku.php

– [email protected]

关于我们

%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BASSL%E5%AE%89%E5%85%A8%E9%97%AE%E9%A2%98

Documents

Transcript of %E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BASSL%E5%AE%89%E5%85%A8%E9%97%AE%E9%A2%98