Bar*_*ard
18
许多因素会影响SSL时间,包括:
基础设施(这不仅会影响SSL,还会影响所有网络流量):
- 由于SSL/TLS握手需要多次往返,因此标准网络问题(服务器与客户端的距离,网络之间的速度等等)).除了更改托管服务提供商和/或使用CDN之外,您几乎无法控制这些内容.根据我的经验,AWS是快速的,您只是要求改进SSL而不是一般访问时间,所以现在可以跳过这个.
- 服务器响应时间.服务器是否处于CPU,Ram或磁盘的供电状态？你是分享这个主人吗？再一般的问题也许可以跳过这个,但SSL/TLS确实需要一些处理能力,现代服务器现在几乎不会引人注意.
- 服务器OS.越新越好.因此,如果运行Red Hat Linux 4,那么期望它比最新的Red Hat Linux 7慢得多,改进的网络堆栈和更新版本的关键软件如OpenSSL.
设置SSL(通过https://www.ssllabs.com/ssltest运行您的网站,您应该获得健康状况):
- 密码使用.有较旧和较慢的密码,更快和新的密码.这里可以很快变得复杂,但一般来说你应该为大多数客户寻找ECDHE密码(并且更喜欢ECDHE ... GCM)并且想要指定应该使用服务器顺序,这样你就可以选择使用的密码而不是客户端.
- 使用证书.您需要RSA 2048证书.更多的是过度和缓慢.一些站点(以及一些扫描工具)选择RSA 4096证书,但这些证书对速度有明显的影响而没有真正增加安全性(此时 - 可能会发生变化).有更新的ECDSA证书(通常在ssllabs报告中显示为256 EC证书)但这些更快的ECDSA证书并非由所有CA提供,并且并非所有客户都普遍支持,因此旧硬件和软件上的访问者可能无法连接他们.Apache(以及最近来自v 1.11.0的Nginx)支持双重证书,以获得两全其美的优势,但代价是拥有两个证书并且设置它们的复杂性.
- 证书链.您需要一个简短的证书链(理想的3证书长度:您的服务器,中介和CA根证书).您的服务器应该返回除最后一个证书之外的所有证书(已经在浏览器证书库中).如果缺少任何链条,某些浏览器会尝试查看沉思的链条,但这需要时间.
- 可靠的证书提供商.除了较短的证书链,更好的OCSP响应者,他们的中介通常也会缓存在用户浏览器中,因为它们很可能被其他站点使用.
- 使用OCSP或CRL,OCSP Stapling可以节省检查证书的网络行程.打开它对Chrome没有任何影响,因为它们不检查撤销(大多数情况下会检查EV证书).它可以对IE产生显着的差异,所以如果您的服务器支持它们应该打开但是要注意一些实现问题 - 特别是当启动OCSP Stapling时,nginx的第一个请求在重启后总是失败.
- 应该使用TLSv1.2,对于较旧的客户端可能使用TLSv1 .0但不使用SSLv2和SSLv3.TLSv1.1有点毫无意义(几乎所有支持它的人都支持更新更好的TLSv1.2).TLSv1.3目前正在开发中并且有一些良好的性能改进,但还没有完全标准化,因为存在一些已知的兼容性问题.希望这些将很快得到解决,以便可以使用.注意PCI合规性(如果在您的网站上使用信用卡)要求在新网站上以及2018年6月30日之前在所有网站上使用TLSv1.2或更高版本.
重复访问 - 虽然上面将有助于初始连接,但大多数站点需要下载多个资源,并且设置错误每次都必须经历整个握手(如果您看到重复的SSL连接设置,这应该是显而易见的运行webpagetest.org之类的每个请求):
- 应该打开HTTP Keep-Alives,以便在每个HTTP请求之后不会丢弃连接(这应该是HTTP/1.1实现的默认设置).
- 在我看来,SSL缓存和门票应该是开启的.有些人不同意某些不明确的安全原因,这些原因应该在TLSv1.3中修复,但出于性能原因应该继续使用.具有高度敏感信息的站点可能会选择更完整的安全性而不是性能,但在我看来,安全性问题的开发非常复杂,性能提升也很明显.
- 应该考虑HTTP/2,因为它只打开一个连接(因此只有一个SSL/TLS设置)并且还有其他性能改进.
我真的需要知道你的网站,看看哪些(如果有的话)可以改进.如果不愿意这样做,那么我建议你运行ssllabs测试并寻求帮助,因为它可能需要大量详细的知识才能理解.
如果有帮助,我会运行一个个人博客,更详细地解释其中的一些概念:https://www.tunetheweb.com/security/https/