我有一个与大多数情况相反的用例：我想以性能的名义实现非常弱的 SSL 密码，如果客户端请求它，可以选择回退到更强的密码。
背景故事：我有一个面向公众的 Web 服务器，它接收来自数千个远程客户端的大量 POST 流量，每个 POST 都相当小。客户端将负载一次并断开连接。服务器每分钟接受数千个这样的连接，因此 SSL 协商的开销加起来。
有问题的数据不需要是安全的；完全使用 HTTPS 的原因是因为流量来自给定网站上的 JavaScript 标记，如果该网站使用 HTTPS，那么我们的补充流量也必须使用 HTTPS，以防止出现有关混合安全和不安全内容的警告。同样，此连接中数据的安全性根本不重要，即使“父”站点出于某种原因受到 SSL 保护。
因此，在保持与浏览器的完全兼容性的同时，向客户端呈现最弱的密码对我来说是有意义的。如果需要，我还想提供提高完整 ECDHE 安全性的选项，只是为了满足更多安全意识强的客户，但绝对是次要选项。
几年前，RC4 的某些变体符合要求，但由于今天普遍认为这是不安全的，我担心浏览器兼容性可能会成为一个问题。在此之后 - 什么密码会以最快的速度为我提供我正在寻找的功能？