关于SSL/TLS中AES安全性|BEAST攻击的详细步骤以及RC4强度的一些笔记

这几天在折腾自己博客SSL全兼容 通过各种渠道给自己科普了SSL/TLS的一些知识。

在此通过自己的大脑概述为尽量简单的语言以加深理解 可能有误 欢迎指出 如果能对你有参考价值那是最好了

闲话到此为止。

在TLS中常用的AES加密 加密强度往往被认为是很高的。但前一阵子爆出的BEAST攻击,对所有TLS1.0中所有的区块加密算法都构成了威胁【包括AES、CAMELLIA等。这些算法在实际应用中需要将需要加密的数据切分成若干块。并对每一块进行加密,最后一块需要填充够足够的长度】。

问题并不是出在加密算法本身,也不是出在密钥交换过程。而是出在区块加密算法所使用的加密工作模式上。SSL/TLS通常采用CBC模式,CBC模式中,为了使得加密的数据看起来有随机性并且不被重放攻击,会将本次需要加密的明文数据块与上次加密好的密文块进行XOR运算后,再通过块加密算法进行本次加密,本次加密好的密文块,又会成为下一块明文块异或的对象

而第一块需要加密的数据是没有前一块数据的 此时需要初始化一个初始化向量对其进行异或。而CBC在具体加密实现里又有两种方式——单独为每一次发送的数据单独初始化向量并加密发送【每发送一段新数据初始化一次向量】,或者在同一个会话里,所有的发送数据只进行一次初始化向量,之后的同一个会话里,一前一后发送的数据AB,B的第一块明文数据,将用A的最后一块密文数据进行异或。SSL/TLS为了效率起见选择了后者

这样的模式在04年被人发现了一个按照当时想法并不切合实际的攻击方式。攻击者如果掌握了SSL发送数据端的发送明文的数据权,并且有能力监听整个通信过程的话,虽然攻击者没有权限获得其它发送的明文的数据,但是可以通过选择性明文攻击来寻找密文对应的平文。 

表述如下【仅供参考 欢迎提意见】:

假如火村向我加密通信约定要在秘密的时间地点【圣诞节 教会】见面,车牌号为音羽69あ978的司机作为攻击者监听了加密的通讯密文,获取了火村通信设备的一部分信息发送权,并且知道火村要在第i个数据段向我提议见面地点。之后火村与我闲聊【这很重要 加密通讯不能断开】。截获了i和i-1数据段的司机,大致猜测火村可能向我提议的见面地点时间地点为P,通过构造一段以下明文数据 加密发送进行攻击:

IVi-1P

注:⊕=异或【科普】。IV=火村与我闲聊所发送的 在注入攻击之前的最后一个数据包。P=司机猜测的见面地点

CBC在处理后 会变为:

IVIVi-1P

由于异或运算的性质,IV将会被抵消。最终传入加密算法的数据会变为:

i-1P

司机将其通过火村端发送,并拦截其结果为R,如果R=i 则代表猜测正确。通过不断的猜测,最终解密到火村将与我在圣诞节的教会见面。然后开着车牌号为音羽69あ978 minori牌卡车的司机七尾奈留【误。。】准时到达教会完成了帽子诅咒。。

咳咳 从以上例子中可以看出 完成这样的攻击需要以下条件:

1、攻击者需要能监听整个SSL/TLS会话过程【这个并不困难】

2、攻击者需要能得到发送敏感数据端的一部分权限。以便将自己的信息插入SSL/TLS会话中【有些困难】

3、攻击者需要完整的猜对整个敏感数据加密数据段的所有信息,这是十分困难的。【就以火村向我提议的时间 和 地点为例 必须同时猜对时间与地点才能攻击成功。而真正在互联网上传送的数据段信息会更多】

4、攻击者需要准确的找出敏感数据的密文段【十分困难】

因此 这样的攻击一般看来是非常难以实现的。但是IETF依旧认为这个攻击很严重。并针对这个攻击 制定了TLSv1.1协议。

回到一开始说的BEAST攻击。BEAST改进了这一攻击方式。

针对第二点,由于互联网上网站经常互相引用混搭,通过Javascript从A站连接B站是可行的。为了防止此类攻击 一般都会对其访问域进行限制。但是这样的限制会显得很不方便,因此站点A访问需要跨域访问站点B时,浏览器一般会询问站点B是否允许。BEAST攻击使用了WebSockets的方式,通过WebSockets,Javascript在进行简单的HTTP握手之后 就可以传输任意的信息,并且综合之前所说的TLS会话通用性,第二点被解决了。

针对第三点,BEAST攻击通过改变数据边界的方式,通过WebSockets操控,将敏感数据“孤立”起来。例如火村与我的例子,攻击者就可以把【圣诞节 教会】整段。拆分为【圣诞节|教会】两段。从而进行单独猜测。听起来似乎挺困难。。但是BEAST攻击论文中提到这样的操作对他们的软件而言是很简单的。BEAST攻击的目标是Cookie。因此经过以上的步骤以后 定位cookie实际上已经变得十分简单 因此第四点也被解决了。

后来由于BEAST攻击所用的WebSockets方式限制相对较高,其团队又提出了用Java来实现攻击,其泛用性更广,并且他们提到他们所使用的Java applet并未做任何提权操作。

这里是攻击视频【来源youtube 自备工具】:

作为运维,防御此类攻击。最佳的办法是升级OpenSSL版本到1.0.1以便支持TLSv1.1和TLSv1.2。并且禁用TLS1.0和SSL3.0中的一切块密钥加密【使用RC4流密钥加密代替块密钥加密】

作为用户,防御此类攻击。办法是直接补全需要加密的网站的https头 不要从HTTP连接中跳转,另外不要在敏感网站待过长时间 离开时切记点退出。不要在公共场所的公用网络【例如CMCC接入等】直接登入需要输入重要信息的网站。

==================================

关于RC4

RC4算法由于在WEP攻击中的弱IVS的表现和算法本身的一些弱点而被诟病。但是现在的TLS中的RC4依旧是安全的【谷歌在TLSv1.0中使用RC4证明了这一点】。虽然RC4有各种实验室的攻击方式 但对于TLS中的客户来说 到目前为止威胁性依旧远低于BEAST攻击。建议为了增强RC4的强度 可以使用ECDHE_RSA进行密钥交换。并且设置会话超时 定时重新换密钥等。

在支持TLSv1.1和v1.2的服务器和浏览器上 使用AES_CBC加密依旧是非常理想的选择.

~以上~

10 个回复 to “关于SSL/TLS中AES安全性|BEAST攻击的详细步骤以及RC4强度的一些笔记”

  1. kitten0 Says:

    有锁头就是好啊
    kitten0的最新文章:行动太快也是一种错误My Profile

    [回复]

  2. bluebear Says:

    mark
    话说如何推测数据是啥?
    bluebear的最新文章:近视眼通过小孔看远处东西更清晰的分析My Profile

    [回复]

    雨宫优子 回复:

    没听明白。。

    [回复]

    bluebear 回复:

    如果要攻击的话,起码要知道对方发的是啥吧
    bluebear的最新文章:关于浮点数计算精度My Profile

    [回复]

    雨宫优子 回复:

    是的。我知道对方肯定要发送cookie 于是针对这个攻击就好。

    [回复]

    bluebear 回复:

    如果协议规定每段信息都要加入一段随机无意义的字符后加密的话,这种攻击是否就无效了
    bluebear的最新文章:关于浮点数计算精度My Profile

    [回复]

    雨宫优子 回复:

    谷歌在后面的浏览器版本修复了下。办法是将敏感信息碎片化。使其难以找到需要猜测的目标。不过只是治标不治本。还是升级用TLS1.1和1.2或者不在TLS1.0里用块密钥加密最好。

  3. 火狐浏览器分割HTTPS报文的问题 | 凯文叔叔的网志 Says:

    […] 4.关于SSL/TLS中AES安全性|BEAST攻击的详细步骤以及RC4强度的一些笔记 – http://xuanwobbs.com.cn/archives/2013-07/ssl-tls-rc4-aes-%E5%AE%89%E5%85%A8%E6%80%A7.html […]

  4. SSL/TLS协议的演化 11–安全问题–BEAST攻击 | 凯文叔叔的网志 Says:

    […] 4.关于SSL/TLS中AES安全性|BEAST攻击的详细步骤以及RC4强度的一些笔记 – http://xuanwobbs.com.cn/archives/2013-07/ssl-tls-rc4-aes-%E5%AE%89%E5%85%A8%E6%80%A7.html […]

  5. ghost Says:

    路过,提醒一下你的证书到期了...
    另外怎么分开设置允许的算法还是有些迷糊,比如说:
    Apache2在TLS1.0时只允许使用RC4,在TLS1.0以上版本只允许使用SHA-AES-256/128
    目前全部是强制SHA-AES,256优先,本来以为很好了结果跑到SSL Labs一看,毛骨悚然...
    回复时麻烦邮件提醒...

    [回复]

为何不留个言呢?

我要把我的最新文章显示在这!