我有一个与大多数情况相反的用例：我想以性能的名义实现非常弱的SSL密码，如果客户端请求，可以select回到更强的密码。
Backstory：我有一个面向公众的Web服务器，它接收来自数千个远程客户端的大量POSTstream量，每个POST都相当小。 客户端将有效载荷一次，并断开连接。 服务器每分钟需要上千个这样的连接，所以SSL协商的开销增加了。
有问题的数据不需要是安全的; 使用HTTPS的原因是因为stream量来自给定网站上的JavaScript标记，如果该网站使用的是HTTPS，则我们的补充stream量必须使用HTTPS以防止混合安全和不安全内容的警告。 同样，即使“父”站点由于某种原因被SSL保护，这个连接中数据的安全性也不重要。
因此，在保持与浏览器完全兼容的同时，向客户端呈现最弱的密码是有意义的。 如果有要求，我还想提供增加安全性的全面ECDHE选项，只是为了满足更多的安全意识的客户，但是绝对是第二select。
几年前，RC4的一些变种可能适合这个法案，但是由于今天这个版本被普遍认为是不安全的，所以我担心浏览器兼容性可能成为一个问题。 在这之后 – 什么密码会以最快的速度为我提供上面我要找的function？
有问题的数据不需要是安全的…防止警告混合安全
我认为你应该理解这些警告的原因，而不是尽可能地忽略它们。 如果安全网站上的内容包含在不安全网站中，则可能会影响到原始网站的安全性。
服务器每分钟需要上千个这样的连接，所以SSL协商的开销增加了。
快速密码通常不会显着减lessSSL协商的开销。 谈判结束后主要使用密码，性能影响不大。 密码的某些部分与握手（密钥交换）相关，但除非您select非常慢的密钥交换（见下文），否则主要的性能影响来自于谈判所需的多次往返。 如果您支持重新使用会话，则只能减less这些限制，以便仅在首次请求时才需要完全握手，并且下一次可以完成同一客户端连接较便宜的会话恢复。 HTTP保持活跃也可以帮助很多。 当然，只有当你实际上有来自同一个客户的多个请求时，这两个优化才能工作。
有一些非常慢的密钥交换密码，你可能不希望在你的情况下使用。 所有DHE- *密码都有很大的性能影响，但具有提供前向保密的优势。 您在ECDHE密码中获得相同的优势，而不会对当今的硬件造成太多的性能影响，但仍然存在开销。 使用AES128-GCM-SHA256等密码在性能和安全性方面应该是一个不错的select。
最后，密码的select也取决于你使用的客户端。 虽然RC4-SHA速度很快，但它被认为是不安全的，越来越多的客户端将其禁用。 因此，你可能和一个快速的服务器没有人可以使用，因为浏览器禁用不安全的密码。
绝对最快的将是eNull。 要在ssl_ciphers中包含eNull，请为您的密码string尝试“aNULL：eNULL：MD5：LOW：HIGH”。 但是，通常情况下，您要协商最高支持的密码。 因此，您可能需要使用！HIGH设置上限，但一定要对此进行彻底testing。 您至less需要保持LOW，因为我相信大多数浏览器都会拒绝使用null和md5密码。
根据您的紧急程度，您可以等待采用“Salsa20”和“ChaCha” ，特别是在性能方面可以直接replaceRC4。 但是，现在只有谷歌浏览器和Android操作系统的最新版本支持它在客户端，它不在OpenSSL，所以没有服务器支持。 否则我同意AES-IN上的其他内容。