我有一个与大多数用例相反的用例：我想以性能的名义实现非常弱的 SSL 密码，并且如果客户端请求，可以选择回退到更强的密码。
背景故事：我有一个面向公众的 Web 服务器，它接收来自数千个远程客户端的大量 POST 流量，每个 POST 流量都很小。客户端将发送一次有效负载并断开连接。服务器每分钟要处理数千个这样的连接，因此 SSL 协商的开销会增加。
所涉及的数据无需安全；使用 HTTPS 的原因是因为流量源自给定网站上的 JavaScript 标记，如果所述网站使用 HTTPS，那么我们的补充流量也必须使用 HTTPS，以防止出现有关混合安全和不安全内容的警告。同样，与此相关的数据安全性根本不重要，即使“父”网站出于某种原因采用 SSL 保护。
因此，我认为向客户端提供最弱的密码，同时保持与浏览器的完全兼容性是有意义的。如果需要，我还想提供将安全性提高到完整 ECDHE 的选项，只是为了满足更注重安全性的客户，但绝对是次要选项。
几年前，RC4 的一些变体可以满足要求，但由于如今普遍认为它不安全，我担心浏览器兼容性可能会成为一个问题。考虑到这一点，哪种密码可以以最快的速度提供我所寻找的上述功能？
答案1
所涉及的数据不需要是安全的...防止有关混合安全的警告
我认为你应该了解这些警告的原因，而不是尽可能地忽略它们。如果安全网站上的内容来自不安全的网站，则可能会影响原始网站的安全性。
服务器每分钟要处理数千个这样的连接，因此 SSL 协商的开销就会增加。
快速密码通常不会显著减少 SSL 协商的开销。密码主要用于后协商已完成，对性能的影响很小。密码的某些部分与握手（密钥交换）相关，但除非您选择非常慢的密钥交换（见下文），否则主要的性能影响来自协商所需的多次往返。只有当您支持会话重用时，才能减少这些影响，这样只需要对第一个请求进行完整的握手，并且下次同一客户端连接时，可以进行更便宜的会话恢复。HTTP 保持活动也可以提供很大帮助。当然，这两种优化只有在您实际上有来自同一客户端的多个请求时才有效。
有些密码的密钥交换速度非常慢，您可能不想在您的案例中使用它们。所有 DHE-* 密码都会对性能产生很大影响，但具有提供前向保密性的优势。ECDHE 密码具有相同的优势，而不会对当今的硬件产生太大的性能影响，但开销仍然存在。使用这样的密码AES128-GCM-SHA256在性能和安全性方面都应该是一个不错的选择。
最后，密码的选择还取决于您使用的客户端。虽然RC4-SHA它速度很快，但它被认为是不安全的，越来越多的客户端禁用它。因此，您可能会使用一个快速的服务器，但没有人可以使用，因为浏览器禁用了不安全的密码。
答案2
绝对最快的是 eNull。要包含eNull在 中ssl_ciphers，请尝试aNULL:eNULL:MD5:LOW:HIGH使用您的密码字符串。通常，但是您将协商支持的最高密码。因此，您可能希望使用 来限制它!HIGH，但一定要彻底测试它。您至少需要保持在 LOW 中，因为我相信大多数浏览器会拒绝使用 null 和 md5 密码。
答案3
答案4
https://discussions.qualys.com/thread/16005列出了批量密码操作和密钥交换的一些基准。对于批量密码，aes128-ccm 似乎是最快的，而对于密钥交换，ecdhe（使用 nist p256）比 2048 位 dhe 快很多，但 rsa 密钥交换稍快一些。 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5551094/列出了密钥交换方法的比较，结果表明 Curve25519（又名 X25519）密钥交换速度明显快于 nist p256）
综合考虑以上所有因素，使用现代处理器和 SSL 库，您最好的选择可能是使用 X25519 进行密钥交换的 TLS_ECDHE_ECDSA_WITH_AES_128_CCM（GCM 套件几乎一样快，而且使用更广泛）。为了提高客户端兼容性，您还可以提供使用 RSA 密钥交换的 TLS_RSA_WITH_AES_128_CBC_SHA。您也可以提供 RC4 套件，但浏览器可能会开始拒绝该算法。这最终取决于您服务器的硬件，因此尝试对几个密码套件进行基准测试并查看每秒可以进行多少次连接可能是个好主意。