如何减少网站的ssl时间 [英] how to reduce ssl time of website

问题描述

我有一个HTTPS网站，我想减少这个网站的SSL时间。 SSL证书已安装在AWS ELB上。

I have an HTTPS website and I want to reduce the SSL time of this website. The SSL certificate has been installed on AWS ELB.

如果我从荷兰访问该网站，则SSL时间很长，但如果我从其他国家/地区访问同一网站，则SSL时间很短。为什么会这样？

If I access the site from Netherlands, the SSL Time is high but if I access the same site from other countries then the SSL time is low. Why is that?

我基本上试图最小化此页面显示的时间

I am basically trying to minimize the time which is showing in this page

http://tools.pingdom.com/ fpt /＃！/ ed9oYJ / https：//www.google.com/index.html

推荐答案

许多影响SSL时间的因素包括：

Many things influence the SSL time including:

基础设施（这不会影响SSL，但所有网络流量）：

Infrastructure (this won't affect just SSL but ALL network traffic):

• 标准网络问题（服务器与客户端的距离，网络之间的速度等等），因为SSL / TLS握手需要几轮旅行。除了更改托管服务提供商和/或使用CDN之外，您几乎无法控制这些内容。根据我的经验，AWS是快速的，您只是要求改进SSL而不是一般访问时间，所以现在可以跳过这个。


• 服务器响应时间。服务器是否处于CPU，Ram或磁盘的供电状态？你是分享这个主人吗？再一般的问题也许可以跳过这个，但是SSL / TLS确实需要一些处理能力，现在的服务器现在几乎看不到它。


• 服务器操作系统。越新越好。因此，如果运行Red Hat Linux 4，那么期望它比最新的Red Hat Linux 7慢得多，改进的网络堆栈和更新版本的关键软件如​​OpenSSL。

设置SSL（通过 https：//www.ssllabs运行您的网站。 com / ssltest 你应该得到一个健康状况）：

SSL set up (run your site through https://www.ssllabs.com/ssltest and you should get a state of health of this):

• 使用的密码。有较旧和较慢的密码，更快和新的密码。这里可以很快变得复杂但通常你应该为大多数客户端寻找ECDHE密码（并且更喜欢ECDHE ... GCM）并且想要指定应该使用服务器顺序，这样你就可以选择使用的密码而不是客户端。


• 使用的证书。您需要RSA 2048证书。更多的东西是矫枉过正和缓慢的。一些站点（以及一些扫描工具）选择RSA 4096证书，但这些证书对速度有明显的影响而没有真正增加安全性（此时 - 可能会发生变化）。有更新的ECDSA证书（通常在ssllabs报告中显示为256 EC证书）但是这些更快的ECDSA证书并非由所有CA提供，并且并非所有客户都普遍支持，因此旧硬件和软件上的访问者可能无法连接他们。 Apache（以及最近的Nginx v 1.11.0 ）支持双重证书，以获得两个方面的优势，但代价是有两个证书，并且设置起来有些复杂。


• 证书链。您需要一个简短的证书链（理想的3个证书长度：您的服务器，中介和CA根证书）。您的服务器应该返回除最后一个证书之外的所有证书（已经在浏览器证书库中）。如果缺少任何链条，一些浏览器将尝试查看沉思的链条，但这需要时间。


• 可靠的证书提供商。除了更短的证书链，更好的OCSP响应者，他们的中介通常也会缓存在用户浏览器中，因为它们很可能被其他网站使用。


• OCSP Stapling节省网络旅行以检查证书使用OCSP或CRL有效。打开它对Chrome没有任何影响，因为它们不会检查撤销（大多数情况下会检查EV证书）。它可以对IE产生明显的影响，所以如果您的服务器支持它们应该打开但是要注意一些实施问题 - 特别是nginx在重启后的第一个请求在OCSP Stapling打开时总是失败。


• 应该使用TLSv1.2，对于较旧的客户端可能使用TLSv1.0但没有SSLv2和SSLv3。 TLSv1.1有点毫无意义（几乎所有支持它的人都支持更新更好的TLSv1.2）。 TLSv1.3目前正在开发中并且有一些良好的性能改进，但还没有完全标准化，因为存在一些已知的兼容性问题。希望这些将很快得到解决，以便可以使用。注意PCI合规性（如果在您的网站上使用信用卡）要求在新网站上以及2018年6月30日之前在所有网站上使用TLSv1.2或更高版本。

• Ciphers used. There are older and slower ciphers and faster and new ones. Can get complicated here really quickly but generally you should be looking for ECDHE ciphers for most clients (and preferable ECDHE...GCM ones) and want to specify that server order should be used so you get to pick the cipher used rather than the client.
• Certificate used. You'll want a RSA 2048 cert. Anything more is overkill and slow. Some sites (and some scanning tools) choose RSA 4096 certificates but these do have a noticeable impact on speed with no real increase in security (at this time - that may change). There are newer ECDSA certs (usually shown as 256 EC cert in ssllabs report) but these faster ECDSA certs are not supplied by all CAs and are not universally supported by all clients, so visitors on older hardware and software may not be able to connect with them. Apache (and very recently Nginx from v 1.11.0) supports dual certs to have best of both worlds but at the expense of having two certs and some complexity of setting them up.
• Certificate Chain. You'll want a short certificate chain (ideal 3 cert long: your server, intermediary and the CAs root certificate). Your server should return everything but the last cert (which is already in browsers certificate store). If any of the chain is missing, some browsers will attempt to look the musing ones but this takes time.
• Reliable cert provider. As well as shorter cert chains, better OCSP responders, their intermediaries also are usually cached in users browsers as they are likely to be used by other sites.
• OCSP Stapling saves network trip to check cert is valid, using OCSP or CRL. Turning it on won't make a difference for Chrome as they don’t check for revocation (mostly but EV certificates do get checked). It can make a noticeable difference to IE so should be turned on if your server supports them but do be aware of some implementation issues - particularly nginx’s first Request after restart always fails when OCSP Stapling is turned on.
• TLSv1.2 should be used and possibly TLSv1 .0 for older clients but no SSLv2 and SSLv3. TLSv1.1 is kind of pointless (pretty much everyone that supports that also supports the newer and better TLSv1.2). TLSv1.3 is currently being worked on and has some good performance improvements but has not been fully standardised yet as there are some known compatibility issues. Hopefully these will be resolved soon so it can be used. Note PCI compliance (if taking credit cards on your site) demands TLSv1.2 or above on new sites, and on all sites by 30th June 2018.

重复访问 - 虽然上面的内容有助于初始连接，但大多数网站都需要下载多个资源，而且每次设置错误都需要经历整个握手（如果您看到重复的SSL，这一点应该很明显运行webpagetest.org之类的每个请求的连接设置）：

Repeat visits - while above will help with the initial connection, most sites require several resources to be downloaded and with bad set up can have to go through whole handshake each time (this should be obvious if you're seeing repeated SSL connection set ups for each request when running things like webpagetest.org):

• HTTP Keep-Alives应该打开，因此连接不是在每个HTTP请求之后删除（这应该是HTTP / 1.1实现的默认设置）。


• 在我看来，SSL缓存和票证应该是开启的。有些人不同意一些不明确的安全原因应该在TLSv1中修复.3 但出于性能原因，他们应该开启。具有高度敏感信息的站点可能会选择更完整的安全性而非性能，但在我看来，安全性问题非常复杂，并且性能提升也很明显。


• 应考虑HTTP / 2 ，因为它只打开一个连接（因此只有一个SSL / TLS设置），并有其他性能改进。

• HTTP Keep-Alives should be turned on so the connection is not dropped after each HTTP Request (this should be the default for HTTP/1.1 implementations).
• SSL caching and tickets should be on in my opinion. Some disagree for some obscure security reasons that should be fixed in TLSv1.3 but for performance reasons they should be on. Sites with highly sensitive information may choose the more complete security over performance but in my opinion the security issues are quite complex to to exploit and the performance gain is noticeable.
• HTTP/2 should be considered, as it only opens one connection (and hence only one SSL/TLS setup) and has other performance improvements.

我真的需要了解您的网站，看看哪些可以改进（如果有的话）。如果不愿意这样做，那么我建议你运行ssllabs测试并寻求帮助，因为它可能需要很多详细的知识才能理解。

I would really need to know your site to see which if above (if any) can be improved. If not willing to give that, then I suggest you run ssllabs test and ask for help with anything it raises you don't understand, as it can require a lot of detailed knowledge to understand.

如果有帮助，我会运行一个个人博客，更详细地解释其中一些概念： https ：//www.tunetheweb.com/security/https/

I run a personal blog explaining some of these concepts in more detail if that helps: https://www.tunetheweb.com/security/https/

这篇关于如何减少网站的ssl时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！