# SSL Speed Up?



## Mike (Sep 9, 2013)

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?


----------



## Dylan (Sep 9, 2013)

Are you talking about the speed difference between HTTP and HTTPS? HTTPS will always be a good deal slower -- generally about 5x -- because a few (four) things have to happen before regular data can be transferred. Here's a cool diagram that shows what's going on:

http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame2.doc_5.1/ss7aumst18.htm


----------



## eva2000 (Sep 9, 2013)

Mike said:


> 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 !


----------



## tchen (Sep 9, 2013)

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.


----------



## HostUS-Alexander (Sep 10, 2013)




----------



## Deleted (Sep 10, 2013)

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 (Sep 10, 2013)

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


----------



## Deleted (Sep 10, 2013)

concerto49 said:


> Enable hardware acceleration on the server. Cache SSL sessions. Balance ciphers for speed/security.


What is 'enable hardware acceleration' ? How does one 'Cache SSL sessions' ?


----------



## Enterprisevpssolutions (Sep 10, 2013)

We use some free tools online to see what is causing the slow down and try to fix it. SSL will always run a little slower. What does your site say when you run it in http://gtmetrix.com/dashboard.html


----------



## acd (Sep 11, 2013)

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.


----------



## Deleted (Sep 12, 2013)

acd said:


> 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)


----------

