我阅读了很多问题 [1]，目前指出该问题RC4已损坏且存在风险。
我刚刚检查了我的网络服务器（nginx），它使用的是默认设置，即
DHE-RSA-AES256-SHA
这个 Cipher 与 RC4 相比如何？
它是否更慢（我认为是这样）但它更安全？
[1] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html
DHE-RSA-AES256-SHA 与 RC4 作为 SSL 的密码相比如何？
信息安全
tls
网页浏览器
http
rc4
2021-08-24 01:01:47
1个回答
密码学上的“破碎”和简单的“破碎”是不同的东西，前者通常被认为是“低于蛮力”（实现起来仍然不可能昂贵）。
除了 AES 和 RC4 这两种密码在内部不同（分别为 CBC 分组密码和流密码）这一事实之外，可观察到的差异是 AES-256 是 256 位的，并且不如您正确建议的那样快（如您正确建议的那样） 128 位 RC4。速度有时是谷歌偏爱它的一个原因。“DHE”部分意味着短暂的 Diffie–Hellman，它提供PFS，通常是一件好事。AES 和 RC4 都支持 SHA-1 和 MD5 进行消息完整性检查，前者是首选（必须使用一个或另一个，在 TLSv1.2 之前添加了更多算法）。
Thomas Pornin 在这里非常巧妙地总结了 RC4 和 BEAST 问题：
RC4 漏洞允许准确猜测连接的前 256 个字节中的大部分内容，至少满足以下条件：
- 在攻击期间，可恢复的内容必须相同
- 攻击者必须捕获大量流量，大约 2 24 —2 32个有用的数据包（他可以将其区分为会话的开始）
- 当他完成后，猜测的内容仍然有用（即 HTTP 会话 cookie）
- SSL 会话密钥没有恢复，只有部分内容
一个快速的粗略计算表明，如果你可以用理想的流量使 wifi 链接（比如 20Mbps）饱和，你会在大约 2 小时内恢复前 3-4 个字节，大约 10 天来恢复 -完全恢复前 256 个字节。（这只是考虑到带宽，分析的 CPU 需求可以忽略不计。）
RC4 的这个问题已经很老了，只是对偏差的量化是新的。
我推荐使用 RC4 上的 AES 密码（BEAST 是客户端问题，如果用户此时仍然有易受攻击的浏览器，则可能需要解决更大的问题）。
尽管其中一些问题（恕我直言）被大肆宣传，但最好的结果是在统一客户端和服务器对 TLSv1.1 及更高版本的支持方面取得了更多进展。大约在 BEAST 发布的时候，支持很差。