On Thu, Aug 4, 2011 at 10:31 AM, Aryeh Gregor <ayg(a)aryeh.name> wrote:
I was under the impression that the biggest cost in
TLS isn't the
symmetric encryption for an ongoing connection, it's the asymmetric
encryption for the connection setup. If so, AES acceleration isn't
going to help with the most important performance issue. Am I wrong?
The handshake operations still aren't all that expensive these days, and
with a prudent amount of sticky loadbalancing to ssl terminating boxes, a
good hit rate can be achieved from openssl's session cache which eliminates
some of the asymmetric operations and half of the connection handshake.
From:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
In January this year (2010), Gmail switched to using HTTPS for everything by
default. Previously it had been introduced as an
option, but now all of our
users use HTTPS to secure their email between their browsers and Google, all
the time. In order to do this we had to deploy *no additional machines*
and *no special hardware*. On our production frontend machines, SSL/TLS
accounts for less than 1% of the CPU load, less than 10KB of memory per
connection and less than 2% of network overhead. Many people believe that
SSL takes a lot of CPU time and we hope the above numbers (public for the
first time) will help to dispel that.
We can't get these sorts of numbers if we run the version of openssl bundled
with lucid but everything we need is available either in patch form or has
become part of the mainline openssl source.