我的 Chrome 刚刚抱怨 PayPal 的安全性，类似于这个问题：
身份已验证，但它抱怨密码学已过时。
说它使用带有 SHA1 的 RC4_128。
我应该担心吗？PayPal应该感到羞耻吗？Chrome 应该停止吓唬我吗？
更新：Chrome 是 v 42，更新到 v 43 后消息停止，现在证书显示 AES_256_CBC - 根据一些评论，这让我相信 Chrome 42 选择使用“RC4_128 和 SHA1” ，而不是贝宝。
糟糕的谷歌：让人们认为服务器有问题，而你的浏览器做出了决定......
这条消息是谷歌试图将人们推入 21 世纪的密码学。因此，当他们看到“RC4”或“SHA-1”时，他们会指指点点并嘲笑。这并不意味着这样的算法可以立即被破解。如果每个人都更喜欢使用算法，即带有 AES/GCM 的 TLS 1.2，Google 会发现世界会变得更美好（或者可能是 googler 的地方）。
实际上，对于 RC4 和 SHA-1 有一些“担忧”，尽管它们都不应该证明对您的通信是致命的：
RC4有已知的偏差。理论上可以利用这些偏差来恢复秘密数据，前提是攻击者可以观察到大量连接（数百万），所有连接都在流中相同的可预测位置包含相同的秘密数据，前提是该秘密在该流中出现得足够早（因为你越往下游走，这些偏差就越低）。最后一个条件是攻击者试图突破 HTTPS 的最大问题。有趣的秘密（HTTP cookie）出现在 HTTP 标头中的位置相对较远。据我所知，到目前为止，还没有在野外发现此类攻击的应用。
SHA-1在抗碰撞方面存在理论上的弱点。尚未产生实际碰撞；理论（被认为是相当可靠的）是构建碰撞将意味着计算成本为 2 61 次函数评估左右，即大大低于预期的 2 80 次（对于具有 160 位输出的函数），但仍然太即使有大量预算的学者也可以随便考虑很多事情。此外，在 TLS 中使用 SHA-1 是通过HMAC 进行的，不会受到冲突的影响。SHA-1 中没有已知的弱点，无论是理论上的还是其他方面的，因为它在 SSL/TLS 中使用。
Paypal 强制执行 RC4 是因为他们希望避免在 CBC 模式下由 AES 引起的感知弱点（所谓的“BEAST 攻击”在实践中不再有效）。如果 Chrome 没有声称它们“过时”，他们肯定会更喜欢，因为这可能会吓跑客户；对于银行来说，安全很重要，但更重要的是要树立安全形象。客户必须感到安全，否则他们会将钱带到别处（这就是为什么大多数 19 世纪的银行都开设了具有非常庞大的建筑、花岗岩柱和钢门的办公室：以灌输一种无意识的稳固感）。