SSL Speed Up?

Mike

New Member
Verified Provider
Here's a question which might spark a nice discussion.

How do you implement changes to speed up SSL negotiations?  We've just installed an SSL onto our website and it seems to have slowed it down a bit - It was much quicker before adding it.

So what do you do to speed up that SSL bottleneck?
 

eva2000

Active Member
Here's a question which might spark a nice discussion.

How do you implement changes to speed up SSL negotiations?  We've just installed an SSL onto our website and it seems to have slowed it down a bit - It was much quicker before adding it.

So what do you do to speed up that SSL bottleneck?
Google SPDY based SSL FTW.

I just created a Nginx SPDY SSL World Flags demo comparing SPDY SSL vs non-SPDY SSL at https://spdy.centminmod.com/spdytest.html. Basically recreating the famous Apache mod_spdy demo video.

The actual Nginx SPDY SSL World Flags demo page https://spdy.centminmod.com/flags.html  B)

Centmin Mod Nginx SSL + Google SPDY setup guide http://centminmod.com/nginx_configure_https_ssl_spdy.html

enjoy !
 
Last edited by a moderator:

tchen

New Member
Turn off DHE ciphers if you're using nginx

from http://techsamurais.com/?p=1384

  ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!AECDH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
  ssl_prefer_server_ciphers on;
That should alleviate some of the strain at least.
 
You'll need a hardware crypto accelerator (PCi-E one) or a processor that supports AES-NI instructions to get better speed. 

An earlier poster suggested these, I'll skip the protocols, but look at the cipher list:

  ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!AECDH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;

The AES() ones are going to be the fastest on the intel hardware due to AES/AES-NI instruction, however, the OTHER computer on other end will have to do the work as well as it's a 'negotiation' between server <-> client (keep that in mind). 

Mixing ECDHE and RC4 do not work correctly with Internet Explorer, so it will fall back to the AES/SHA from what I remember. Personally, I'd use the AES instructions. 
 

concerto49

New Member
Verified Provider
Enable hardware acceleration on the server. Cache SSL sessions. Balance ciphers for speed/security.
 

acd

New Member
Mathematically, I'd expect more time is lost in the asymmetric part of bringing an SSL connection up than the stream/block symmetric cipher part, and that part doesn't have the advantages of instruction set acceleration. On the other hand it only has to be done once per connection, and if your server keeps connections alive, it doesn't need to rebuild the ssl pipe. Something to think about.
 
Mathematically, I'd expect more time is lost in the asymmetric part of bringing an SSL connection up than the stream/block symmetric cipher part, and that part doesn't have the advantages of instruction set acceleration. On the other hand it only has to be done once per connection, and if your server keeps connections alive, it doesn't need to rebuild the ssl pipe. Something to think about.
On SSL, Session init() is expensive due to socket calls, and entropy from SSL itself. Opening up /dev/urandom on any *NIX OS takes a very long time, due to stat64() call on /dev/random then an open(), then finally a read()

Long ago apache had to disable KeepAlives/Pipelines on SSL connections because they couldn't do it safely without breaking things towards the browser (IE2-7 had broken keepalives with apache which hurt performance)

SSE2 gives SSL a nice speedup, AVX gives it a faster speedup, and AVX-NI gives it the fastest speedup I have seen (per apachebench and a production server)
 
Top