这几天在折腾自己博客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，通过构造一段以下明文数据 加密发送进行攻击：

IV⊕i-1⊕P

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

CBC在处理后 会变为：

IV⊕IV⊕i-1⊕P

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

i-1⊕P

司机将其通过火村端发送，并拦截其结果为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加密依旧是非常理想的选择.

~以上~