5

colleagues!

Well, I am with a huge problem with the speed of SSL Authentication. Since I move my website to SSL, the GoogleBot reduce the indexing of my website, because the SSL Negotiation is with below value I got with WebPageTest.org:

URL: https://www.musiconline.com.br/jorge-e-mateus/alcapao/

Host: www.musiconline.com.br

Error/Status Code: 200

Client Port: 0

Start Offset: 0.735 s

DNS Lookup: 34 ms

Initial Connection: 170 ms

SSL Negotiation: 531 ms

Time to First Byte: 311 ms

Content Download: 178 ms

Bytes In (downloaded): 13.2 KB

Bytes Out (uploaded): 0.4 KB

Look, the "SSL Negotiation" is in 531ms, a big value.

Someone know how can I solve this issue?

I verified the mod_spdy, however, I can't install because the follow message in my Linux CentOS 6, Apache 2.4:

root@server1 [/home/login/src]# rpm -U mod-spdy-*.rpm

warning: mod-spdy-beta_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY

error: Failed dependencies:

    httpd >= 2.2.4 is needed by mod-spdy-beta-0.9.4.3-420.x86_64

    mod_ssl >= 2.2 is needed by mod-spdy-beta-0.9.4.3-420.x86_64

root@server1 [/home/login/src]# httpd -v

Server version: Apache/2.4.12 (Unix)

Server built: Mar 21 2015 10:58:04

Cpanel::Easy::Apache v3.28.4 rev9999

root@server1 [/home/molbr/src]# uname -a

Linux server1.musiconline.com.br 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Thanks for assistance.

Andre Luis de Andrade
  • 55
  • 1
  • 5
  • This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/), [Web Apps Stack Exchange](http://webapps.stackexchange.com/), [Webmaster Stack Exchange](http://webmasters.stackexchange.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. – jww Mar 23 '15 at 08:26
  • Also see [Do the ChaCha: better mobile performance with cryptography](https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/) for a patch. According to [Speeding up and strengthening HTTPS connections for Chrome on Android](http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html), the cipher suites are 2x to 4x faster than AES/GCM. Sadly, its *still* not available in OpenSSL (see [ChaCha20/Poly1305 in OpenSSL?](https://groups.google.com/d/msg/mailing.openssl.users/VYCwNQokyWo/9FPNVXZ5_1gJ)). – jww Mar 23 '15 at 15:36
  • @jww: since the performance problem is during the SSL handshake it does not matter much which symmetric cipher is chosen. – Steffen Ullrich Mar 23 '15 at 18:07
  • @Steffen - agreed that key agreement/exchange is usually a pain point. But its not clear to me that's dominating the [perceived] performance problems since the question has little in the way of details. He could also run a 64-bit machine and configure OpenSSL with `enable-ec_nistp_64_gcc_128` because its 2x to 4x faster for EC. He should also be keeping his cipher suite list small by calling `SSL_CTX_set_cipher_list` (that could save an extra TCP segment in the `ClientHello`). He could also ensure high performance ciphers at the server by calling `SSL_CTX_set_cipher_list` with only EC.... – jww Mar 23 '15 at 18:15
  • @jww: see [my answer](http://stackoverflow.com/a/29199493/3081018) for what the problem is in my opinion: (uselessly) too large certificate chain causing bad interactions with TCP slow start. – Steffen Ullrich Mar 23 '15 at 18:44

1 Answers1

4

Initial Connection: 170 ms

SSL Negotiation: 531 ms

Looking at a packet capture I can see that after the initial TCP handshake the client starts the Handshake and it then it takes a long time for the server to send all necessary data back (ServerHello, Certificates...). These data need 5 packets and due to various TCP magic and OS tuning the last packet will only be send once it got the acknowledgements for previous packets. In detail this TCP magic might probably be TCP slow start with a fixed initial congestion windows of 4 with the CentOS version you use (see https://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start/).

What can you do: fix you certificate chain. If you look at the SSLLabs report you will see "Chain issues: Contains anchor" which means that you send the root certificate even though the root certificate will be ignored by the client and instead a trusted CA built into the client is used (trust chain must be built from local trust!). If you fix your configuration by removing this root certificate the data sent by the server will be shorter and you will not run into the slow-start problem.

Community
  • 1
  • 1
Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172