如果不需要强度,Nginx的最快SSL密码实现?

Modified on: Mon, 15 Apr 2019 21:20:02 +0800

我有一个与大多数情况相反的用例:我想以性能的名义实现非常弱的SSL密码,如果客户端请求,可以选择回退到更强的密码。

背景故事:我有一个面向公众的Web服务器,它接收来自数千个远程客户端的大量POST流量,每个POST都相当小。客户端将有效负载一次并断开连接。服务器每分钟接管数千个这样的连接,因此SSL协商的开销加起来。

有问题的数据不需要是安全的;使用HTTPS的原因是因为流量来自给定网站上的JavaScript标记,如果所述网站使用HTTPS,那么我们的补充流量也必须使用HTTPS以防止混合安全和不安全内容的警告。同样,即使“父”站点因任何原因而受到SSL保护,此连接中数据的安全性也不重要。

因此,在保持与浏览器的完全兼容性的同时,向客户提供最弱的密码是有意义的。如果需要,我还想提供增加安全ECDHE安全性的选项,仅仅是为了满足更多注重安全性的客户,但绝对是次要选择。

几年前,RC4的某些变体可能符合要求,但由于今天普遍认为它不安全,我担心浏览器兼容性可能会成为一个问题。在那之后 - 什么密码会以最快的速度为我提供我正在寻找的功能?

最佳答案

  

有问题的数据不需要是安全的......请防止有关混合安全的警告

我认为您应该理解这些警告的原因,而不是仅仅尽可能地忽略它们。如果安全站点上的内容包含在不安全的站点中,则可能会影响原始站点的安全性。

  

服务器每分钟接管数千个这样的连接,因此SSL协商的开销会增加。

快速密码通常不会显着降低SSL协商的开销。密码主要在协商完成后使用,并且只有很小的性能影响。密码的某些部分与握手(密钥交换)相关,但除非您选择非常慢的密钥交换(见下文),否则主要的性能影响来自协商所需的多次往返。如果您支持会话的重用,则只能减少这些,因此只有第一个请求才需要完全握手,并且下次同一个客户端连接较便宜的会话恢复时也可以完成。 HTTP keep-alive也可以提供很多帮助。当然,只有当您实际上有来自同一客户端的多个请求时,这两个优化才起作用。

有一些密码交换非常慢的密码,您可能不希望在您的情况下使用。所有DHE- *密码都具有很大的性能影响,但具有提供前向保密的优势。使用ECDHE密码可以获得相同的优势,而不会对当今的硬件产生太大的性能影响,但仍然存在开销。在性能和安全性方面,使用AES128-GCM-SHA256等密码应该是一个不错的选择。

最后,密码的选择还取决于您使用的客户端。虽然RC4-SHA很快,但它被认为是不安全的,越来越多的客户端禁用它。因此,您可以使用快速服务器,因为浏览器禁用了不安全的密码,所以没有人可以使用。


相关问答

添加新评论