Here some Benchmarks with aes-256-cbc:
##OpenSSL 0.9.8
16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
165967.40k 176138.69k 178376.08k 165082.46k 178232.41k
### OpenSSL 1.0.1 without AES-NI (without kernel extension loaded)
16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
240935.91k 258555.73k 261316.44k 266033.49k 260849.66k
### OpenSSL 1.0.1 with AES-NI (without kernel extension loaded)
16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
525472.77k 545694.68k 560349.27k 557427.03k 557694.98k
### OpenSSL 1.0.1 with AES-NI (with kernel extension loaded)
16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
524809.01k 548448.30k 560363.26k 555793.62k 557424.64k
So you can see that OpenSSL will use AES-NI without the kernel
extension. I think the kernel extension is only needed on FreeBSD if you
want a /dev/aesni device.
Kind regards,
John
Aristedes Maniatis wrote:
On 27/05/2014 6:59pm, Lukas Tribus wrote:
Hi,
Without purchasing specific expensive add-on cards [1], is there
something specific to some modern CPUs which will accelerate SSL
handling in haproxy 1.5?
That is, should I be looking for something in a CPU which will
improve performance considerably? There is an Intel instruction
set called AES-NI but I don't know if that applies to HTTPS#
traffic. As I understand, the initial negotiation in SSL is rsa/dsa
but then the payload is transported using symmetric key encryption
(like AES?).
I'm only looking to handle about 50Mb/s of SSL traffic, so I'm not
aiming very high. But it would be nice to know the headroom is there.
Bandwidth is not really the limiting factor, handshakes per second is.
AES-NI gives you a nice performance boost but doesn't help with handshakes
afaik.
Whats important, among other points, is having enough entropy, and the RDRAND
feature of modern CPUs can help you there (if you trust your CPU vendor).
Otherwise, there some software projects like haveged or audio entropy daemon
that can feed random data in the kernel.
Keep-alive and session id resumption are very important features to scale
a SSL enabled site, so double check that those things are working properly.
Right, so then it isn't about AES at all, but the public key negotiation and
key generation. We are running on Freebsd 10 which feeds /dev/random from
yarrow and that in turn grabs entropy from the CPU and other places. So I think
we should be good since we are unlikely to run out of entropy there.
aesni_load="YES" in loader.conf should take care of the AES side of things
If the NSA wanted credit card numbers they could just go get them from
Mastercard directly, and there isn't really much else of great espionage
interest in the transactional data. So I'm not overly concerned about the
backdoors in the Intel CPUs.
Thanks for the useful information.
Ari
--
John-Paul Bader | Software Development
www.wooga.com
wooga GmbH | Saarbruecker Str. 38 | D-10405 Berlin
Sitz der Gesellschaft: Berlin; HRB 117846 B
Registergericht Berlin-Charlottenburg
Geschaeftsfuehrung: Jens Begemann, Philipp Moeser
