今天我遇到了网站https://mtgox.com/，该网站声称由于 Verisign 证书是安全的。我出于好奇检查了证书（这是他们声称的第一件事，让我们看看“安全”有多安全），它是 128 位 RC4 和 MD5 用于消息身份验证。
据我所知，AES 是目前最好的对称加密算法。RC4 似乎也不错，但 Wikipedia 反对将其用于新系统。然后是 MD5……尽管有很多批评，但当你在哈希上没有足够大的赏金时，它似乎实际上足够安全，但使用它仍然有很多批评。
另请注意，明文在这里是部分已知的，就像文档类型的一部分<head>，当然还有文档类型。我不确定这是否可以用于 RC4 攻击。
那么这个密码套件到底有多安全呢？篡改这种连接需要什么？或者在无限时间的情况下读取传输的数据需要什么？是否有更低的套件在使用，例如常见但有些过时的浏览器（如 FF3.6、IE8 等）？
RC4 现在不被认为是安全的，有文档明确禁止在 TLS 中使用它：RFC7465。
您目前不应该使用 RC4。
发布更新为有关加密的过时信息是危险的
2012 年发布的过时信息：
RC4 是安全的，事实上，如果您不使用 TLS 1.2，那么您应该使用 RC4 来防止 BEAST。
MD5 是不安全的，但如果它被用作 MAC 函数，它还没有被破坏
值得称赞的是，如果您禁用了 MD5 哈希，它将与 SHA-1 协商，事实上，如果您禁用 RC4，它将协商 AES：https ://www.ssllabs.com/ssltest/analyze.html?d=mtgox %2ecom&s=72%2e52%2e5%2e67
目前（2013 年 3 月）RC4 的已知弱点是统计偏差：
流的前几个字节，尤其是第二个字节，相当有偏差，这意味着如果攻击者观察到大量 SSL 会话，他可以很好地猜测客户端或服务器发送的第二个字节可能是什么（在会议开始时）。但这并不能教会他太多东西：攻击者已经知道客户端发送的第二个字节是“E”（对于 HTTP 'GET' 请求），而服务器发送的第二个字节是“T”（对于HTTP 响应，始终以“HTTP”开头）。
其他偏差是关于不太可能的字节对。在观察 1 GB 的 RC4 输出后，可以显示出偏差。但是，观察实验室条件的偏差，以及对加密数据进行推断，是两件不同的事情。没有已知的方法可以将 RC4 的这种偏见转化为对 SSL 的实际攻击（我听说过的最合理的场景是观察数十亿个连接，这些连接都包含相同的秘密数据，例如 cookie 或密码，可靠地可预测的地方——只需要几千年的耐心窃听）。
目前（2013 年 3 月）MD5 的已知弱点是：
在 SSL 中使用时，它们都不会直接影响 MD5。实际上，SSL 使用 MD5 作为HMAC的一部分，它有一个“安全证明”，将其安全性与 MD5 中使用的压缩功能是否与PRF无法区分。已知MD5的压缩函数不是PRF；它自 1996 年以来就为人所知，而 Dobbertin 在该压缩函数上的工作。这使得 HMAC 安全证明“不适用”。但是 HMAC/MD5 没有被证明是安全的，并不意味着它被证明是不安全的。目前尚不知道对 HMAC/MD5 的实际攻击。相应地，它在 SSL 中的使用仍然是“安全的”。
这与MD5 的前身MD4的情况得到印证。MD4在碰撞方面非常糟糕，比 MD5 严重得多（构建 MD5 碰撞仍然需要几秒钟，而同一台机器每秒会构建数百万次 MD4 碰撞）。对 MD4 的原像攻击也是已知的，但只是理论上的（成本为 2 102）。HMAC/MD4 具有“几乎实用”的攻击，导致 2 58次 查询中的伪造（您必须说服受攻击的 SSL 客户端或服务器在同一会话中根据攻击者选择的数据计算那么多 SSL 记录，然后再生成一个伪造记录）。这意味着如果SSL 使用的是 MD4 而不是 MD5，它现在仍然是“实际安全的”，我们只会有“高级警告标志”，表明需要迁移到更好的东西。MD5 在所有方面都比 MD4 更健壮，因此无需恐慌。
而且，当然，这些都与证书无关。服务器是否要使用 RC4 或 AES 或 MD5 或 SHA-256未写在证书中，并且完全超出了 Verisign 可能想要做的任何事情。证书的工作在服务器public key处结束，并且不包括服务器对该公钥所做的事情，更不用说服务器对使用公钥交换的任何会话密钥所做的事情。
没有针对此密码套件的已知攻击。我不会称其为“弱”。选择这个密码套件并不是我所说的最佳实践——但如果其他人为你做出了选择，而你却一直在使用它，那么你可能会没事的。它不太可能成为您系统中最薄弱的环节。