Est*_*nza 5 performance ssl nginx
我有一个与大多数情况相反的用例：我想以性能的名义实现非常弱的 SSL 密码，如果客户端请求它，可以选择回退到更强的密码。
背景故事：我有一个面向公众的 Web 服务器，它接收来自数千个远程客户端的大量 POST 流量，每个 POST 都相当小。客户端将负载一次并断开连接。服务器每分钟接受数千个这样的连接，因此 SSL 协商的开销加起来。
有问题的数据不需要是安全的；完全使用 HTTPS 的原因是因为流量来自给定网站上的 JavaScript 标记，如果该网站使用 HTTPS，那么我们的补充流量也必须使用 HTTPS，以防止出现有关混合安全和不安全内容的警告。同样，此连接中数据的安全性根本不重要，即使“父”站点出于某种原因受到 SSL 保护。
因此，在保持与浏览器的完全兼容性的同时，向客户端呈现最弱的密码对我来说是有意义的。如果需要，我还想提供提高完整 ECDHE 安全性的选项，只是为了满足更多安全意识强的客户，但绝对是次要选项。
几年前，RC4 的某些变体符合要求，但由于今天普遍认为这是不安全的，我担心浏览器兼容性可能会成为一个问题。在此之后 - 什么密码会以最快的速度为我提供我正在寻找的功能？
有问题的数据不需要是安全的......防止警告混合安全
我认为您应该了解这些警告的原因，而不是尽可能地忽略它们。如果安全站点上的内容来自不安全站点，则可能会影响原始站点的安全。
服务器每分钟接受数千个这样的连接，因此 SSL 协商的开销加起来。
快速密码通常不会显着减少 SSL 协商的开销。密码主要在协商完成后使用，对性能的影响很小。密码的某些部分与握手（密钥交换）相关，但除非您选择非常慢的密钥交换（见下文），否则主要的性能影响来自协商所需的多次往返。只有在您支持会话重用的情况下才能减少这些，因此只有第一个请求才需要完整的握手，并且下次相同的客户端连接时可以完成更便宜的会话恢复。HTTP keep-alive 也有很大帮助。当然，只有当您实际上有来自同一客户端的多个请求时，这两种优化才有效。
有些密码的密钥交换速度非常慢，您可能不想在您的情况下使用它们。所有 DHE-* 密码对性能都有很大的影响，但具有提供前向保密的优势。您可以使用 ECDHE 密码获得相同的优势，而不会对当今的硬件产生太大的性能影响，但开销仍然存在。AES128-GCM-SHA256就性能和安全性而言，使用像这样的密码应该是一个不错的选择。
最后，密码的选择还取决于您使用的客户端。虽然RC4-SHA速度很快，但它被认为是不安全的，越来越多的客户端禁用它。因此，您可能会使用一个没人可以使用的快速服务器，因为浏览器禁用了不安全的密码。